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INTEGRATED PROXY INTERFACE FOR separate environments and are maintained independently of 

WEB BASED DATA MANAGEMENT each other. The StarPR server provides a batch reporting 

REPORTS mechanism focused primarily on providing billing data to 

l-800/8xx, VNET, Vision, and other MCI customers and is 

CROSS-REFERENCE TO RELATED 5 used by MCI customers predominantly to do internal charge 

APPLICATIONS backs and to analyze billing usage. Alternately, or in 

The following patent application is based on and claims addi,i °°i customeis use the data provided to them to do 

the benefit of U.S. Provisional Patent Application Ser. No. cM U!imc a™ 1 * 515 ' similar to TVS. 

60/060,655, filed Sep. 26, 1997. With specific reference to FIG. 1, the data collected is in 

10 the form of call detail records which are created by various 

FIELD OF THE INVENTION MCI/Concert switches (not shown) whenever a telephone 

The present invention relates generally to information cidl * attem P' ed M * e MCI ° etwork lnd wl f h includes 

delivery systems and, particularly, to a novel, World Wide "Nation about call type call origination and termination 

Web/Internet-based, telecommunications network data man- „ locations, date and time, added intelligent network services, 

agement reporting and presentation service for customers of 15 ^ ho P ^formation, product type and other relevant infor- 

telecommunications service entities. m ^™tT ^ Ca ' L NetW ° rk Info ™ aUOD F onc ^ ,ra - 

tor ( NIC ) component 15 is a network element that collects 

BACKGROUND OF THE INVENTION the CDRs and sends them to appropriate locations via a 

^ , . irT , orT , Global Statistical Engine 17. The Global Statistical Engine 

Telecommunications service entities e.g MCI, AT&T, M 1? coUects ^ CDRs and tfansf processeS) ^ sends 

Sprint, and the like presently provide for the presentauon ^ to ^ ^ ^ ^ ^ ^ ^ tQ ^ ^ 

and dissemination 01 customer account and network data . . . t , A t ... 

... . . . ■ i through vanous statistical reports and real time monitoring 

management lntormation to their customers predominantly ^ ^ 22 ("RTM"") 

by enabling customers (clients) to directly dial-up, e.g., via en g me \ )• 

a modem, to the entity's application servers to access their « ™^ C P£ S from \ re ako !f? to ., the Whngsystem which 
account information, or, alternately, via dedicated commu- ^ ^ based on call detad values These priced 
nication lines, e.g., ISDN, T-l, etc., enabling account infer- CDRs are "BiUmg Detail Records ( BDRs ) and 
mation requests to be initiated through their computer ter- m S6D ' '° Host ( Phost ) server 25. The Phost 
minal running, for example, a Windows®-based graphical S6rv6 f " filters out thc ^DRs not pertaining to the Per- 
user interface. The requests are processed by the entity's 30 s P ect,ve customers, applies vanous transformations to the 
application servers, which retrieves the requested customer cus J tomer s raw f 1 } delai1 data to f ne [ atc summary data, 
information, e.g., from one or more databases, processes and ^ Borates and formats the data for the various Perspec- 
formats the information for downloading to the client's fe customers. This data is then compressed, sent to a 
computer terminal document service center ( DSC ) and CD-ROM dispatcher 

„ 4 , ' « • j» « j -i j * * • ("CDD") 34 entities which respectively, uncompresses the 

Some types of data, e.g.. "priced call detail data pertain- 35 \ 4 , , n m* • lu * > 

Jtr , ,1 ■ «• . • data and burns CD-ROMs comprising the customer s raw 

ing to a customer s telecommunications number usage, is , 4 , t , , \ . 4 c 

& , 1 ui c * • * j j call detail data and summary data, in addition to reference 

made available for customers m an aggregated or processed C1 , 1* 7* t c 1 

c , .... , * • files and possibly application software (if not previously 

form and provided to customers, e.g., on a monthly basis. ,v \ r ' : r A c \ • j* j- 

This type of data is analyzed to determine, for example, asset 7f K ed > « a Wmg customer to perform analysis and trending 

j * jt • * L- u • ■ j * of their Perspective data. These CD-ROMs are sent to the 

usage and trend information necessary, which is required for 40 „ -n- 1 1L1 , . , 

* , t , ... iu • j •• a customers, usually on a billing cycle or monthly basis, who 

network managers to make critical business decisions. As an . 4 . . ' 4 , „ 1 * i 

, 4 . & . t . . 4 . . . .™ „ view their data through a Perspective workstation-based 

example, the assignee telecommunications earner MCI Cor- £l .... ... 4 . , ^„ 

J 0 x>r/-,T o * ir / (<W p inft , « software apphcation residmg on that customer s CPE, e.g., 
poration provides an MCI Service view ( MSV ) product pr , £ r . « 
1 • r> *j t * j 1 • 1 • 1 1 ir or ^^vo^lcslatlon 00. 
line ror its business customers which includes several client- 
server based data management applications. One of these 45 M shown ™ FIG * ^ existing Perspective Host 25 
applications, referred to as "Perspective", provides call mainframe-based data delivery system interfaces with all 
usage and analysis information that focuses on the presen- Perspective upstream feed systems, including billing sys- 
tation of and priced call detail data and reports from an MCI tems and order entrv > md processes the data, e.g., creates 
Perspective Data Server ("StarPR"). Another client-server canned a Bg re g ates > f° r delivery to the document service 
based data management application, referred to as "Traffic 50 r - 

View", focuses on the presentation of real time call detail The following upstream feed systems include: 1) order 

data and network traffic analysis/monitor information as entry information from a customer order entry system 19 

provided from an MCI Traffic view server. Particularly, with ("CORE") and which information is used by the Perspective 

respect to MCPs Perspective system, customers are pro- Host to determine what customer data to process and where 

vided with their monthly priced and discounted raw call 55 to send it; 2) VNET and Vision monthly billing data feeds 

detail data, call detail aggregates, and statistical historical from a commercial billing system ("KBCS") system 23; 3) 

summary data. As such, the Perspective architecture is a Toll-free monthly billing data feed from a T/F database 

organized primarily as a batch midrange-based server data feed 27; and, a Concert Virtual Network Services ("CVNS") 

delivery mechanism with the data being typically delivered product feed from a CVNS database 31. In order for all the 

on a monthly basis, allowing for "delayed" trending, call eo CDR and data feed information to be processed by the Phost 

pattern analysis, repricing and invoice validation based on server 25, various reference files and processing rules are 

the customer's call detail data. The trending, analysis, and provided including: alphanumeric translation reference files 

repricing functionality is maintained in workstation-based from the NCBS billing system 23 and an NPA/NXX-state- 

software provided to customers for installation at customer city and country code lookup reference file originating from 

sites on their PCS. 65 a calling area data base ("CADB") 35. 

FIG. 1 illustrates the current architecture 10 for Perspec- While effective for its purpose, the current data manage - 

tive and Traffic View Systems which presently run on ment and presentation architecture only provides customers 
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with their priced call detail data on a monthly basis, usually ments a Data Warehouse approach to maintaining data 

in the form of a canned report. This is not sufficient for an obtained from upstream billing systems, i.e., priced call 

increasing number of customers who, to remain competitive, detail data, and which data may be made readily available 

are required to have updated and real-time access to their for reporting on a daily basis. In this approach, priced call 

data to enable them to make their critical business decisions 5 detail data is maintained in datamarts and operational data 

quicker. Moreover, there are a variety of independent data stores capable of meeting real-time processing and storage 

management tools and legacy reporting systems having requirements. Particularly, these datamarts may be parti- 

disparate systems and infrastructures providing little or no Uoned based on vanou ? ***n*, e.g., customer id to enable 

cross application interoperability and data sharing, thus, casi K e , r management of data by providing scalability and 

. . * J t / ■ ' „ enabling more control of over hardware and software 

requinng customers to use separate applications to gain 10 ^ a CTgt<ffec|ive way , in this datamart 

access to their data. approach is a back-end server component provided to 
Furthermore, existing telecommunications service pro- receive data access requests from various users in the form 
vider reporting systems are limited in that reports generated 0 f a report request, interactive data analysis request or data 
are of a narrow view, and are delivered at predetermined mining request. This server routes the query to the appro- 
times with predetermined formats. These prior art reporting 15 priate data marts, data warehouse or operational data store 
systems do not enable the generation of ad-hoc reports. and responds to the requestor with the result set. 
Moreover, legacy platforms including reporting data are The nMCI Interact system is a layer functioning to enable 
reaching the architectural limits of scalability in terms of the customers to request reporting functionality across the Inter- 
total customers they can support, total online data they can net. This report request functionality includes routing 
present, total historical data they can keep and type and 20 requests to appropriate datamarts, e.g., real-time reporting 
number of applications they can support. requests will be satisfied by real-time database. Additionally, 
It would thus be highly desirable to provide a data ^ intcrfa ^ e P rovid f s «wfomcis with the ability to schedule 
j * *if * • W i l j /t * * j and prioritize reports, format report request result sets, and 
management product that is a Web-based (Internet and K. - , j\ , . r . n , , 4 - 

& * v provides for load balancing, report request validation, query 



Ilntranet) client-server application providing priced call generation and execution. Through a common GUI, custom- 
detail data information to customers in a variety of detailed ^ ^ enMed {Q access ^ own metered ^ ^ 
report formats comprising specific customer account infor- Perspective or usage analysis data. 

matron. j n accordance with the principles of the present invention, 

It would additionally be highly desirable to provide a there is provided a Web/Internet based reporting system for 

Web -based (Internet and Ilntranet) data management tool 3Q communicating data information from an enterprise intranet 

having a unique back-end infrastructure for a Web -based database to a client terminal via an integrated interface 

client-server application which provides expedient and comprising: a client browser application located at the client 

secure data access and reporting services to customers at any terminal for enabling interactive Web based communica- 

time, from any web browser on any computer terminal tions with the reporting system, the client terminal identified 

anywhere in the world. with a customer and providing the integrated interface; at 

35 least one secure server for managing client sessions over the 

SUMMARY OF THE INVENTION Internet, the secure server supporting a first secure socket 

_ . . . , ' „ , connection enabling encrypted communication between the 

The present invention is directed to a novel Ilntranet/ browsef applicaU0D client md the ^ cure a dispatch 

Internet/Web-based data management tool that provides a server for mmnandca!dag ^th lhe secure serve r through a 

common GUI enabling the requesting, customizing, sched- 40 fi rewa ii over a seC ond socket connection, the first secure and 

uling and viewing of various types of priced call detail data second sockets forming a secure communications link, the 

reports pertaining to a customer's usage of telecommunica- dispatch server enabling forwarding of a report request 

tions services. The Intranet/Interne t/Web -based reporting message and an associated report response message back to 

system tool comprises a novel Web -based, client-server the client browser over the secure communications link; a 

application integrated with an operational data management/ 45 report manager server for maintaining an inventory of 

storage infrastructure that enables customers to access their reporting items associated with a customer and managing 

own relevant data information timely, rapidly and accurately the reporting of customer-specific data information in accor- 

through the GUI client interface. The operational database dance with a customer request message, the report manager 

system infrastructure particularly is configured to meet a accessing reporting items based on a customer identity and 

customer's real-time data processing and storage require- 50 report name from a first database, and generating a response 

ments and is easy to deploy and manage, and further, ensures message including a metadata description of the reporting 

upward and downward scalability. It enables effective star- itcms i and > dec * 10D ^PP 0 * sc ™ cx interfacing with the 

age of data from a variety of independently developed report manager for accessing the customer-specific data 

legacy systems and, is readily integrated into a novel Web- from me ^.f 6 m * anet database m accordance ™ th ^ 

u j n * * j t * *\ * * 1 a. « customer identity and report name, wherein the retrieved 

based (Internet ^ intranet) reporting system tool that S 5 data and the metodata descripdon of .he reporting item are 

enables customers to customize and directly access their , . „ „ w e n f 

, .rr, 111 utilized to generate a completed report tor presentation to 

own relevant data report information. The world wide web/ the ^ fa interface. 

Internet-based client-server data management and reporting Advantageously, the novel Web/Internet based reporting 

tool employs a platform-independent, 1 e., JAVA-based, net- ffl mt atcd with ^ ^ managem ent system permits 

work centric GUI client presentation layer and an objects/ 60 uge of cxisUn hardwarc whilc allowing future growth to 

dispatcher/proxy layer access architecture. new cquipment at lcss cost md allows for 

Particularly, the telecommunications data management/ incremental expansion as applications and database capaci- 

system architecture is integrated with a novel Web/Internet ties grow, 
based reporting system, referred to as networkMCI Interact 

("nMCI"), described in co-pending U.S. patent application 65 BRIEF DESCRIPTION OF THE DRAWINGS 

Ser. No. 09/159,409. The back-end data management/ Further features and advantages of the invention will 

system architecture, referred to herein as "StarODS", imple- become more readily apparent from a consideration of the 
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following detailed description set forthwith reference to the 2) a network architecture defining the physical network 

accompanying drawings, which specify and show preferred needed to satisfy the security and data volume require- 

embodiments of the invention, wherein like elements are ments of the networkMCI System; 

designated by identical references throughout the drawings; 3) a data architecture detailing the application, back-end 

and in which: 5 or legacy data sources available for networkMCI Inter- 

FIG. 1 illustrates conceptually an existing mainframe- act > and 

based data delivery system 10 providing customer's call 4 ) an infrastructure covering security, order entry, 

detail data- fulfillment, billing, self -monitoring, metrics and sup- 

FIG. 2 illustrates the software architecture component „ P° rt * , .,1 . « 

comprising a three-tiered structure; 10 Jt E«* ° f J*"? common component areas will be generally 

• j- • • u- discussed hereinbelow. A detailed descriptions or each of 

FIG. 3 is a diagrammatic overview of the software arcm- ^ ncnts can be folind in a tM tj. S . 

lecture of the networkMCI Interact system; ^ ap ^ cation Scr No 09 /159,695, entitled INTE- 

HG. 4 is an illustrative example of a backplane architec- GRATED CUSTOMER INTERFACE SYSTEM FOR 

ture schematic; 15 COMMUNICATIONS NETWORK MANAGEMENT, the 

FIG. 5 illustrates an example client GUI presented to the disclosure of which is incorporated herein by reference 

client/customer as a browser web page; thereto. 

FIG. 6 is a diagram depicting the physical networkMCI FIG. 2 is a diagrammatic illustration of the software 

Interact system architecture; architecture component in which the present invention func- 

FIG. 7 is a block diagram depicting the physical archi- 20 tions. A first or client tier 40 of software services are resident 

tecture of the StarWRS component of networkMCI Interact on a customer work station and provides customer access to 

Reporting system; the enterprise system, having one or more downloadable 

FIG. 8 illustrates the primary components implemented in application objects directed to front end business logic, one 

the StarODS priced reporting component 400; or more backplane service objects for managing sessions, 

FIG. 9 illustrates the data model implemented for access- 25 one or , more P^sentatioo services objects for the presenta- 

. r * • * f. . c Aj ™ Uon of customer options and customer requested data in a 

ing information used in priced reporting system of nMCI , . * c , , * , 

I ? r ct • browser recognizable format and a customer supplied 

_ w , .„ , « . , „ r^r,n browser for presentation of customer options and data to the 

HG. 10(a) illustrates the logical Report Manager/DSS c ^ m&v and fof mtemet municauons over ^ public 

application programming interface; 3Q mterQet Additionally applications are directed to front end 

HG. 10(b) illustrates the logical DSS/Report Manager services such as the presentation of data in the form of tables 

application programming interface; arld chartSj ^ data process i ng functions such as sorting and 

FIGS. ll(a)-ll(6) illustrate an overview of the process summarizing in a manner such that multiple programs are 

performed by the DSS in routing a request; combined in a unified application suite. A second or middle 

HG. 12(a) illustrates an overview of the DSS connections 35 tier 42, is provided having secure web servers and back end 

enabling guaranteed message delivery in the nMCI Interact services to provide applications that establish user sessions, 

System; govern user authentication and their entitlements, and com- 

FIG. 12(b) illustrates the formatter process implemented municate with adaptor programs to simplify the interchange 

in the DSS server; of data across the network. 

FIGS. n(ayiXc) illustrate the end-to-end process 600 40 A third or back end ^ 45 havirj g applications ^cled to 

for fulfilling priced report request; le S acv back end services including database storage and 

t-t^. u'li t t 1-1 r * * c *u retrieval systems and one or more database servers for 

FIG. 14 illustrates a logical message format sent irom the . ' - , , t 

x . . , . , -jji r accessing system resources from one or more legacy hosts, 

client browser to the desired middle tier server tor a par- _ * J . . , . . - j- 

r Generally, as explained in commonly owned, co -pending 

ticular application; and 45 ^ * > Ser. No. 09/159,515, now U.S. Pa* 

FIGS. 15(a) and 15(b) are schematic illustrations showing Nq Ml5)040? entitled GRAPHICAL USER INTERFACE 

the message format passed between the Dispatcher server FQR WEB ENA BLED APPLICATIONS, the disclosure of 

and the application specific proxy (FIG 15(a)) and the which fc ^ rated herein by re f er ence thereto, the cus- 

message format passed between the application specific tomer workstation client software capable of pro . 

proxy back to the Dispatcher server (FIG. 15(b)). $Q yiding a plat f onn _ mde p endent) browser-based, consistent 

DETAILED DESCRIPTION OF THE user mter f ace implementing objects programmed to provide 

INVENTION a reusa °l e and common GUI abstraction and problem- 
domain abstractions. More specifically, the client-tier soft- 

The present invention is one component of an integrated ware ^ crea ted and distributed as a set of Java classes 
suite of customer network management and report applica- ss including the applet classes to provide an industrial strength, 
tions using a Web browser paradigm. Known as the net- object-oriented environment over the Internet. Application- 
workMCI Interact system ("nMCI Interact") such an inte- specific classes are designed to support the functionality and 
grated suite of Web-based applications provides an server interfaces for each application with the functionality 
invaluable tool for enabling customers to manage their delivered through the system being of two-types: 1) cross- 
telecommunication assets, quickly and securely, from any- 60 pro duct, for example, inbox and reporting functions, and 2) 
where in the world. product specific, for example, toll free network management 

As described in co-pending U.S. patent application Ser. or Call Manager functions. The system is capable of deliv- 

No. 09/159,695, the nMCI Interact system architecture is ering to customers the functionality appropriate to their 

basically organized as a set of common components com- product mix. 

prising the following: 65 FIG. 3 is a diagrammatic overview of the software archi- 

1) an object-oriented software architecture detailing the tecture of the networkMCI Interact system including: the 

client and server based aspect of nMCI Interact; Customer Browser (a.k.a. the Client) 50; the Demilitarized 
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Zone (DMZ) 47 comprising a Web Servers duster 44; the Plane which keeps track of all the client applications, and 

MCI Intranet Dispatcher Server 46; and the MCI Intranet which has capabilities to start, stop, and provide references 

Application servers 60, and the data warehouses, legacy to any one of the client applications, 

systems, etc. 80. The backplane 52 and the client applications use a 

A customer workstation 51 employs a Web Browser 50 5 browser 50 such as the Microsoft Explorer versions 4.0.1 or 

implementing client applications responsible for presenta- higher for an access and distribution mechanism. Although 

tion and front-end services. Its functions include providing the backplane is initiated with a browser 14, the client 

a user interface to various MCI services and supporting applications are generally isolated from the browser in that 

communications with MCTs Intranet web server cluster 44. they typically present their user interfaces in a separate 

As illustrated in FIG. 3, and more specifically described in 10 frame, rather than sitting inside a Web page, 

the above-mentioned, co-pending U.S. patent application The backplane architecture is implemented with several 

Ser. No. 09/159,515, now U.S. Pat. No. 6,115,040, entitled primary classes. These classes include COBackPlane, 

GRAPHICAL USER INTERFACE FOR WEB ENABLED COApp, COAppImpl, COParm. and COAppFrame classes. 

APPLICATIONS, the client tier software is responsible for COBackPlane 52 is an application backplane which 

presentation services to the customer and generally includes 15 launches the applications 54a, 54fc, typically implemented as 

a web browser 50 and additional object-oriented programs COApp. COBackPlane 52 is generally implemented as a 

residing in the client workstation platform 51. The client Java applet and is launched by the Web browser 50. This 

software is generally organized into a component architec- backplane applet is responsible for launching and closing the 

ture with each component generally comprising a specific COApps. 

application, providing an area of functionality. The applica- 20 When the backplane is implemented as an applet, it 

tions generally are integrated using a "backplane" services overrides standard Applet methods init( ), start( ), stop( ) and 

layer 52 which provides a set of services to the application run( ). In the init( ) method, the backplane applet obtains a 

objects which provide the front end business logic and COUser user context object. The COUser object holds 

manages their launch. The networkMCI Interact common information such as user profile, applications and their 

set of objects provide a set of services to each of the 25 entitlements. The user's configuration and application 

applications such as: 1) session management; 2) application entitlements provided in the COUser context are used to 

launch; 3) inter-application communications; 4) window construct the application toolbar and Inbox applications, 

navigation among applications; 5) log management; and 6) When an application toolbar icon is clicked, a particular 

version management. COApp is launched by launchApp( ) method. The launched 

The primary common object services include: graphical 30 application then may use the backplane for inter-application 

user interface (GUI); communications; printing; user communications, including retrieving Inbox data, 

identity, authentication, and entitlements; data import and The CoBackPlane 52 includes methods for providing a 

export; logging and statistics; error handling; and messaging reference to a particular COApp, for interoperation. For 

services. example, the COBackPlane class provides a getApp( ) 

FIG. 4 is a diagrammatic example of a backplane archi- 35 method which returns references to application objects by 

tecture scheme illustrating the relationship among the com- name. Once retrieved in this manner, the application object's 

mon objects. In this example, the backplane services layer public interface may be used directly. 

52 is programmed as a Java applet which can be loaded and The use of a set of common objects for implementing the 

launched by the web browser 50. With reference to FIG. 4, various functions provided by the system of the present 

a typical user session starts with a web browser 50 creating 40 invention, and particularly the use of browser based objects 

a backplane 52, after a successful logon. The backplane 52, to launch applications and pass data therebetween is more 

inter alia, presents a user with an interface for networkMCI fully described in the above-referenced, copending applica- 

Interact application management. A typical user display tion GRAPHICAL USER INTERFACE FOR WEB 

provided by the backplane 52 may show a number of ENABLED APPLICATIONS. 

applications the user is entitled to run, each application 45 As shown in FIG. 3, the aforesaid objects will commu- 

rep resented by buttons depicted in FIG. 4 as buttons 58a, b, c nicate the data by establishing a secure TCP messaging 

selectable by the user. As illustrated in FIG. 4, upon selec- session with one of the DMZ networkMCI Interact Web 

tion of an application, the backplane 52 launches that servers 44 via an Internet secure communications path 32 

specific application, for example, Service Inquiry 54a or established, preferably, with a secure sockets SSL version of 

Alarm Monitor 54fc, by creating the application object. In 50 HTTPS. The DMZ networkMCI Interact Web servers 44 

processing its functions, each application in turn, may utilize function to decrypt the client message, preferably via the 

common object services provided by the backplane 52. FIG. SSL implementation, and unwrap the session key and verify 

4 shows graphical user interface objects 56a,b created and the users session. After establishing that the request has 

used by a respective application 54a, b for its own presen- come from a valid user and mapping the request to its 

tation purposes. 55 associated session, the DMZ Web servers 44 will re-encrypt 

FIG. 5 illustrates an example client GUI presented to the the request using symmetric encryption and forward it over 

client/customer as a browser web page 71 providing, for a second socket connection 33 to the dispatch server 46 

example, a suite 70 of network management reporting inside the enterprise Intranet. 

applications including: MCI Traffic Monitor 72; an alarm As described in greater detail in commonly owned, 

monitor 73; a Network Manager 74 and Intelligent Routing 60 co-pending U.S. patent application Ser. No. 09/159,514, 

75. Access to network functionality is also provided through now allowed, entitled SECURE CUSTOMER INTERFACE 

Report Requester 76, which provides a variety of detailed FOR WEB-BASED DATA MANAGEMENT, the contents 

reports for the client/customer and a Message Center 77 for and disclosure of which is incorporated by reference as if 

providing enhancements and functionality to traditional fully set forth herein, a networkMCI Interact session is 

e-mail communications. 65 designated by a logon, successful authentication, followed 

As shown in FIGS. 3 and 4, the browser resident GUI of by use of server resources, and logoff. However, the world - 

the present invention implements a single object, COBack- wide web communications protocol uses HTTP, a stateless 
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protocol, each HTTP request and reply is a separate TCP/IP system -specific Report Manager server 62 for generating, 

connection, completely independent of all previous or future managing and scheduling the transmission of customized 

connections between the same server and client. The nMCI reports including, for example: call usage analysis informa- 

Interact system is implemented with a secure version of tion provided from the StarODS server 63; network traffic 

HTTP such as S-fflTP or HTTPS, and preferably utilizes 5 analysis/monitor information provided from the Traffic view 

the SSL implementation of HTTPS. The preferred embodi- server 64 i virtual data network alarms and performance 

ment uses SSL which provides a cipher spec message which rc P orts . provided by Broadband server 65; trouble tickets for 

provides server authentication during a session. The pre- switching, transmission and traffic faults provided by Ser- 

ferred embodiment further associates a given HTTPS V1CC *W T se ™ % a f nd free routing information 

j . 4 . . . , . i_- i_ j j 4 i j provided by Toll Free Network Manager server 67. 

request with a logical session which is initiated and tracked 10 M ^ shown m FJG 3 ft is ^ nderstood ^ each 

bya cookie jar server 5 48 to generate a cookie which is i ntran et server of suite 60 communicates with one or several 

a unique server-generated key that is sent to the client along ^0^^ netW ork databases which include each custom- 

with each reply to a HTTPS request. The client holds the er > s nctwork management information and data. In the 

cookie and returns it to the server as part of each subsequent prc sent invention the Services Inquiry server 36 includes 

HTTPS request. As desired, either the Web servers 44, the 15 communication with MCI's Customer Service Management 

cookie jar server 48 or the Dispatch Server 46, may maintain legacy platform 80(a). Such network management and cus- 

the "cookie jar" to map these keys to the associated session. tomer network data is additionally accessible by authorized 

A separate cookie jar server 48, as illustrated in FIG. 3 has MCI management personnel. As shown in FIG. 3, other 

been found desirable to minimize the load on the dispatch legacy platforms 80(£>), 80(c) and 80(d) may also commu- 

server 46. This form of session management also functions 20 nicate individually with the Intranet servers for servicing 

as an authentication of each HTTPS request, adding an specific transactions initiated at the client browser. The 

additional level of security to the overall process. illustrated legacy platforms 80(a)-(tz) are illustrative only 

As illustrated in FIG. 3, after one of the DMZ Web servers and it is understood other legacy platforms may be inter- 
44 decrypts and verifies the user session, it forwards the preted into the network architecture illustrated in FIG. 3 
message through a firewall 55b over a TCP/IP connection 33 25 through an intermediate midrange server 60. 
to the dispatch server 46 on a new TCP socket while the Each of the individual proxies may be maintained on the 
original socket 32 from the browser is blocking, waiting for dispatch server 46, the related application server, or a 
a response. The dispatch server 46 will unwrap an outer separate proxy server situated between the dispatch server 
protocol layer of the message from the DMZ services cluster 46 and the midrange server 30. The relevant proxy waits for 
44, and will re encrypt the message with symmetric encryp- 30 requests from an application client running on the custo na- 
tion and forward the message to an appropriate application er's workstation 50 and then services the request, either by 
proxy via a third TCP/IP socket 37. While waiting for the handling them internally or forwarding them to its associ- 
proxy response, all three of the sockets 32, 33, 37 will be ated Intranet application server 60. The proxies additionally 
blocking on a receive. Specifically, once , the message is receive appropriate responses back from an Intranet appli- 
decrypted, the wrappers are examined to reveal the user and 35 cation server 60. Any data returned from the Intranet app li- 
the target middle -tier (Intranet application) service for the cation server 60 is translated back to client format, and 
request. A first-level validation is performed, making sure returned over the internet to the client workstation 50 via the 
that the user is entitled to communicate with the desired Dispatch Server 46 and at one of the web servers in the DMZ 
service. The user's entitlements in this regard are fetched by Services cluster 44 and a secure sockets connection. When 
the dispatch server 46 from StarOE server 69 at logon time 40 the resultant response header and trailing application spe- 
and cached. cific data are sent back to the client browser from the proxy, 

If the requestor is authorized to communicate with the the messages will cascade all the way back to the browser 14 

target service, the message is forwarded to the desired in real time, limited only by the transmission latency speed 

service's proxy. Each application proxy is an application of the network. 

specific daemon which resides on a specific Intranet server, 45 The networkMCI Interact middle tier software includes a 

shown in FIG. 3 as a suite of mid-range servers 60. Each communications component offering three (3) types of data 

Intranet application server of suite 60 is generally respon- transport mechanisms: 1) Synchronous; 2) Asynchronous; 

sible for providing a specific back-end service requested by and 3) Bulk transfer. Synchronous transaction is used for 

the client, and, is additionally capable of requesting services situations in which data will be returned by the application 

from other Intranet application servers by communicating to so server 60 quickly. Thus, a single TCP connection will be 

the specific proxy associated with that other application made and kept open until the full response has been 

server. Thus, an application server not only can offer its retrieved. 

browser a client to server interface through the proxy, but Asynchronous transaction is supported generally for situ- 

also may offer all its services from its proxy to other ations in which there may be a long delay in application 

application servers. In effect, the application servers request- 55 server 60 response. Specifically, a proxy will accept a 

ing service are acting as clients to the application servers request from a customer or client 50 via an SSL connection 

providing the service. Such mechanism increases the secu- and then respond to the client 50 with a unique identifier and 

rity of the overall system as well as reducing the number of close the socket connection. Hie client 50 may then poll 

interfaces. repeatedly on a periodic basis until the response is ready. 

Hie network architecture of FIG. 3 may also include a 60 Each poll will occur on a new socket connection to the 

variety of application specific proxies having associated proxy, and the proxy will either respond with the resultant 

Intranet application servers including: a StarOE proxy for data or, respond that the request is still in progress. This will 

the StarOE application server 69 for handling authentication reduce the number of resource consuming TCP connections 

order entry/billing; an Inbox proxy for the Inbox application open at any time and permit a user to close their browser or 

server 61, which functions as a container for completed 65 disconnect a modem and return later to check for results, 

reports, call detail data and marketing news messages, a Bulk transfer is generally intended for large data transfers 

Report Manager Proxy capable of communicating with a and are unlimited in size. Bulk transfer permits cancellation 
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during a transfer and allows the programmer to code the public Internet 85. When a subscriber connects to the 

resumption of a transfer at a later point in time. networkMCI Interact Web site by entering the appropriate 

FIG. 6 is a diagram depicting the physical networkMCI URL, a secure TCP/IP communications link 32a is estab- 

Interact system architecture 100. As shown in FIG. 6, the lished to one of several Web servers 44 located inside a first 

system is divided into three major architectural divisions 5 firewall 55a in the DMZ 47. Preferably at least two web 

including: 1) the customer workstation 50 which include servers are provided for redundancy and failover capability, 

those mechanisms enabling customer connection to the In the preferred embodiment of the invention, the system 

Secure web servers 44; 2) a secure network area 47, known employs SSL encryption so that communications in both 

as the DeMilitarized Zone "DMZ" set aside on MCI pre- directions between the subscriber and the networkMCI 

mises double firewalled between the both the public Internet 10 Interact system are secure. 

85 and the MCI Intranet to prevent potentially hostile In the preferred embodiment, all DMZ Secure Web serv- 
customer attacks; and, 3) the MCI Intranet Midrange Servers ers 44 are preferably DEC 4100 systems having Unix or 
60 and Legacy Mainframe Systems 80 which comprise the NT-based operating systems for running services such as 
back end business logic applications. HTTPS, FTP, and Telnet over TCP/IP. The web servers may 

As illustrated in FIG. 6, the present invention includes a 15 be interconnected by a fast Ethernet LAN running at 100 

double or complex firewall system that creates a "demilita- Mbit/sec or greater, preferably with the deployment of 

rized zone" (DMZ) between two firewalls 55a, 556. In the switches within the Ethernet LANs for improved bandwidth 

preferred embodiment, one of the firewalls 556 includes port utilization. One such switching unit included as part of the 

specific filtering routers, which may only connect with a network architecture is a Hydra WEB® unit 82, manufac- 

designated port address. For example, router 84 (firewall 20 tured by HydraWEB Technologies, Inc., which provides the 

55(a)) may connect only to the addresses set for the DMZ with a virtual IP address so that subscriber HTTPS 

HydraWeb® (or web servers 44) within the DMZ, and router requests received over the Internet will always be received. 

86 (firewall 55(b)) may only connect to the port addresses The Hydra web® unit 82 implements a load balancing algo- 
set for the dispatch server 46 within the network. In addition, rithm enabling intelligent packet routing and providing 
the dispatch server 46 connects with an authentication 25 optimal reliability and performance by guaranteeing acces- 
server, and through a proxy firewall to the application sibility to the "most available" server. It particularly moni- 
servers. This ensures that even if a remote user ID and tors all aspects of web server health from CPU usage, to 
password are hijacked, the only access granted is to one of memory utilization, to available swap space so that Internet/ 
the web servers 44 or to intermediate data and privileges Intranet networks can increase their hit rate and reduce Web 
authorized for that user. Further, the hijacker may not 30 server management costs. In this manner, resource utiliza- 
directly connect to any enterprise server in the enterprise tion is maximized and bandwidth (throughput) is improved, 
intranet beyond the DMZ, thus ensuring internal company It should be understood that a redundant Hydraweb® unit 
system security and integrity. Even with a stolen password, may be implemented in a Hot/Standby configuration with 
the hijacker may not connect to other ports, root directories heartbeat messaging between the two units (not shown), 
or application servers within the enterprise system, and the 35 Moreover, the networkMCI Interact system architecture 
only servers that may be sabotaged or controlled by a hacker affords web server scaling, both in vertical and horizontal 
are the web servers 44. directions. Additionally, the architecture is such that new 

The DMZ 47 acts as a double firewall for the enterprise secure web servers 44 may be easily added as customer 

intranet because of the double layer of port specific filtering requirements and usage increases. 

rules. Further, the web servers 44 located in the DMZ never 40 As shown in FIG. 6, the most available Web server 44 

store or compute actual customer sensitive data. The web receives subscriber HTTPS requests, for example, from the 

servers only transmit the data in a form suitable for display HydraWEB® 82 over a connection 44b and generates the 

by the customer's web browser. Since the DMZ web servers appropriate encrypted messages for routing the request to 

do not store customer data, there is a much smaller chance the appropriate MCI Intranet midrange web server over 

of any customer information being jeopardized in case of a 45 connection 44a, router 86 and connection 44£>. Via the 

security breach. In the preferred embodiment, firewalls or Hydraweb® unit 82, a TCP/IP connection 38 links the 

routers 84, 86 are a combination of circuit gateways and Secure Web server 44 with the MCI Intranet Dispatcher 

filtering gateways or routers using packet filtering rules to server 46. 

grant or deny access from a source address to a destination Further as shown in the DMZ 47 is a second RTM server 

address. All connections from the internal application serv- 50 92 having its own connection to the public Internet via a 

ers are proxied and filtered through the dispatcher before TCP/IP connection 88. As described in co -pending U.S. 

reaching the web servers 44. Thus it appears to any remote patent application Ser. No. 09/159,516, entitled INTE- 

site, that the connection is really with the DMZ site, and GRATED PROXY INTERFACE FOR WEB BASED 

identity of the internal server is doubly obscured. This also TELECOMMUNICATIONS MANAGEMENT TOOLS, 

prevents and direct connection between any external and any 55 this RTM server provides real-time session management for 

internal network or intranet computer. subscribers of the networkMCI Interact Real Time Moni- 

The filtering firewalls 55(a), (b) may also pass or block toring system. An additional TCP/IP connection 88a links 

specific types of Internet protocols. For example, FTP can be the RTM Web server 92 with the MCI Intranet Dispatcher 

enabled only for connections to the In-Box server 61, and server 46. As further shown in FIG. 6, a third router 87 is 

denied for all other destinations. SMTP can also be enabled 60 provided for routing encrypted subscriber messages from the 

to the In-Box server, but Telnet denied. The In-box server 61 RTM Web server 92 to the Dispatcher server 46 inside the 

is a store and forward server for client designated reports, second firewall. Although not shown, each of the routers 86, 

but even in this server, the data and meta-data are" separated 87 may additionally route signals through a series of other 

to further secure the data, as will be described. routers before eventually being routed to the nMCI Interact 

As previously described, the customer access mechanism 65 Dispatcher server 46. In operation, each of the Secure 

is a client workstation 51 employing a Web browser 50 for servers 44 function to decrypt the client message, preferably 

providing the access to the networkMCI Interact system via via the SSL implementation, and unwrap the session key and 
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verify the users session from the COUser object authenti- 
cated at Logon. 

After establishing that the request has come from a valid 
user and mapping the request to its associated session, the 
Secure Web servers 44 will re -encrypt the request using 
symmetric RSA encryption and forward it over a second 
socket connection 38 to the dispatch server 46 inside the 
enterprise Intranet. 

As described herein, and in greater detail in co-pending 
U.S. patent application Ser. No. 09/159,695, the data archi- 
tecture component of networkMCI Interact reporting system 
is focused on the presentation of real time (un-priced) call 
detail data, such as provided by MCI s TrafficView Server 
64, and priced call detail data and reports, such as provided 
by MCI s StarODS Server 63 in a variety of user selected 
formats. 

All reporting is provided through a Report Requestor GUI 
application interface which support spreadsheet, a variety of 
graph and chart types, or both simultaneously. For example, 
the spreadsheet presentation allows for sorting by any arbi- 
trary set of columns. The report viewer may also be launched 
from the inbox when a report is selected. 

A common database may be maintained to hold the 
common configuration data which can be used by the GUI 
applications and by the mid-range servers. Such common 
data will include but not be limited to: customer security 
profiles, billing hierarchies for each customer, general ref- 
erence data (states, NPA's, Country codes), and customer 
specific pick lists: e.g., ANFs, calling cards, etc. An MCI 
Internet StarOE server will manage the data base for the 
common configuration of data. 

Report management related data is also generated which 
includes 1) report profiles defining the types of reports that 
are available, fields for the reports, default sort options and 
customizations allowed; and 2) report requests defining 
customer specific report requests including report type, 
report name, scheduling criteria, and subtotal fields. This 
type of data will be resident in an Inbox server database and 
managed by the Inbox server. 

The Infrastructure component of the dMCI Reporting 
system includes means for providing secure communica- 
tions regardless of the data content being communicated. As 
described in detail in above-referenced, co-pending U.S. 
patent application Ser. No. 09/159,514, now allowed, the 
nMCI Interact system security infrastructure includes: 1) 
authentication, including the use of passwords and digital 
certificates; 2) public key encryption, such as employed by 
a secure sockets layer (SSL) encryption protocol; 3) 
firewalls, such as described above with reference to the 
network architecture component; and 4) non-repudiation 
techniques to guarantee that a message originating from a 
source is the actual identified sender. One technique 
employed to combat repudiation includes use of an audit 
trail with electronically signed one-way message digests 
included with each transaction. 

Another component of the nMCI Interact infrastructure 
includes order entry, which is supported by the Order Entry 
("StarOE") server. The general categories of features to be 
ordered include: 1) Priced Reporting; 2) Real-time report- 
ing; 3) Priced Call Detail; 4) Real Time Call Detail; 5) 
Broadband SNMP Alarming; 6) Broadband Reports; 7) 
Inbound RTM; 8) Outbound RTM; 9) Toll Free Network 
Manager; and 10) Call Manager. The order entry function- 
ality is extended to additionally support 11) Event Monitor; 
12) Service Inquiry; 13) Outbound Network Manager; 14) 
Portfolio; and, 15) Client View. 

The Self -monitoring infrastructure component for nMCI 
Interact is the employment of mid- range servers that support 
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SNMP alerts at the hardware level. In addition, all software 
processes generate alerts based on process health, 
connectivity, and availability of resources (e.g., disk usage, 
CPU utilization, database availability). 

5 The Metrics infrastructure component for nMCI Interact 
is the employment of means to monitor throughput and 
volumes at the Web servers, dispatcher server, application 
proxies and mid-range servers. Metrics monitoring helps in 
the determination of hardware and network growth. 

10 To provide the areas of functionality described above, the 
client tier 50 is organized into a component architecture, 
with each component providing one of the areas of func- 
tionality. As explained in further detail in co-pending U.S. 
patent application Ser. No. 09/159,515, now issued as U.S. 

15 Pat. No, 6,115,040, the client -tier software is organized into 
a "component" architecture supporting such applications as 
inbox fetch and inbox management, report viewer and report 
requestor, TFNM, Event Monitor, Broadband, Real-Time 
Monitor, and system administration applications. Further 

20 functionality integrated into the software architecture 
includes applications such as Outbound Network Manager, 
Call Manager, Service Inquiry and Client View. 

The present invention focuses on the client and middle - 
tier service and application proxy components that enable 

25 customers to request, specify, customize, schedule and 
receive their telecommunications network call detail data 
and account information in the form of reports that are 
generated by the various back-end application servers. 
Referred to herein as "StarWRS", this WWW/Internet 

30 Reporting System 200, as shown in FIG. 7, comprises the 
following components and messaging interfaces: 

1) those components associated with the Client GUI front 
end including a report requester client application 212, 
a report viewer client application 215 and, an Inbox 

35 client application 210 which implement the logical 
processes associated with a "Java Client", i.e., employs 
Java applets launched from the backplane (FIG. 3) that 
enable the display and creation of reports and graphs 
based on the fields of the displayed reports, and, allows 

40 selection of different reporting criteria and options for 
a given report; and, 

2) those middle-tier server components enabling the 
above-mentioned reporting functionality including: a 
Report Manager server 250, a Report scheduler server 

45 260, and an Inbox Server 270. Also shown in FIG. 7 are 
the system Order Entry client application 280 and a 
corresponding Order Entry Server 285 supporting the 
StarWRS reporting functionality as will be described. 
Each of these components will now be described with 
50 greater particularity hereinbelow. 

The Report Manager ("RM") server 250 is an application 
responsible for the synchronization of report inventory with 
the back-end "Fulfilling" servers 300; retrieval of 
entitlements, i.e., a user's security profiles, and report pick 
55 list information, i.e., data for user report customization 
options, from the system Order Entry server 280; the trans- 
mission of report responses or messages to the Dispatcher 
server 26 (FIG. 7); the maintenance of the reporting data- 
bases; and, the management of metadata used for displaying 
60 reports. In the preferred embodiment, the RM server 250 
employs a Unix daemon that passively listens for connect 
requests from the GUI client applications and other back- 
end servers and deploys the TCP/IP protocol to receive and 
route requests and their responses. Particularly, Unix stream 
65 sockets using the TCP/IP protocol suite are deployed to 
listen for client connections on a well-known port number 
on the designated host machine. Client processes, e.g., 
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report requestor 212, wishing to submit requests connect to message may be sent to indicate when a requested report is 

RM 250 via the dispatcher 26 by providing the port number in the Inbox server 270. 

and host name associated with RM 250. Request messages As shown in FIG. 7, the report scheduler server 260 
received by the RM server are translated into a "metadata" interfaces directly with the Report Manager server 250 to 
format and are validated by a parser object built into a report 5 coordinate report request processing. The respective report 
manager proxy 250' that services requests that arrive from management and scheduling functions could be performed 
the GUI front-end. If the errors are found in the metadata in a single server. An overview of the report request/ 
input, the RM 250 returns an error message to the requesting scheduling process implemented by StarWRS Report Man- 
client. If the metadata passes the validation tests, the request ager and Report Requestor tools may be found in commonly 
type will be determined and data will be retrieved in 10 owned, co-pending U.S. patent application Ser. No. 09/159, 
accordance with the metadata request after which a response 409, entitled INTEGRATED PROXY INTERFACE FOR 
will be sent back to the requesting client. WEB BASED REPORT REQUESTOR TOOL SET, the 
As shown in FIG. 7, interface sockets 252 are shown contents and disclosure of which is incorporated by refer- 
connecting the Dispatcher server 46 and the RM server 250 ence as if fully set forth herein. 

and, other socket connections 254, 256 provide the interface 15 The Inbox Server component 270 serves as the repository 

between the RM 250 and respective middle tier systems 400 where the completed user report data is stored, maintained, 

and 500. For instance, fulfilling system 400 receives and eventually deleted and is the source of data that is 

requests for a customer's priced billing data through a uploaded to the client user via the dispatcher over a secure 

publish-and-subscribe Talarian smart socket messaging socket connection 272. It is also a Unix program that is 

interface 350 providing guaranteed message delivery of 20 designed to handle and process user requests submitted in 

messages from the Report Manager. It should be understood metadata format using an Informix database. Once report 

that the RM 250 server can manage reporting data for results are received from the StarODS 400 and TVS 500 and 

customer presentation from other middle- tier and back-end any other middle tier or fulfilling servers, the Inbox server 

legacy systems including, e.g., Traffic View, Broadband, 270 requests the metadata from the Report Manager server 

Service Inquiry, etc. in order to present to a customer these 25 250 as indicated by the socket connection 272 in FIG. 7. The 

types of network management data. metadata is stored in the Inbox server database 273 along 

The report manager server additionally utilizes a database with the report results. Thus, if the metadata is required to 

258, such as provided by Informix, to provide accounting of be changed, it will not interfere with the information needed 

metadata and user report inventory. Preferably, an SQL to display the reports contained in the Inbox. Additionally, as 

interface is utilized to access stored procedures used in 30 shown in FIG, 7, the Inbox server interfaces with the report 

processing requests and tracking customer reports. A variety scheduler to coordinate execution and presentation of 

of C++ tools and other tools such as Rogue Wave's reports. 

tools.h++ are additionally implemented to perform metadata The StarOE server 280 is the repository of user pick lists 

message parsing validation and translation functions. and user reporting entitlements as shown in database 283. 

The Report Manager server 250 additionally includes the 35 Particularly, it is shown interfacing with the Inbox server 

scheduling information, however, a report scheduler server 270 and report scheduler servers 260. The Report Manager 

component passes report requests to the back-end fulfilling does not interface with or include metadata for StarOE. It 

systems 400, 500 at the scheduled times. will, however, include information in the report metadata 

The Report Scheduler ("RS") server component 260 is a that will tell the Report Requestor it needs to get information 

perpetually running Unix daemon that deploys the TCP/IP 40 (i.e., Pick Lists) from StarOE server 285. Particularly, as 

protocol to send requests to the back-end fulfilling servers shown in Appendix A, the StarOE server supports pick lists 

400, 500, and receive their responses. More particularly, the for the selection of priced data based on the following list: 

RS server 260 is a Unix server program designed to handle Date, Time (e.g., provided in GMT offset), ID Accounting 

and process report requests to the fulfilling servers by Code (IDACC)/Supp code, Access Type, Corp ID, Service 

deploying Unix stream sockets using the TCP/IP protocol 45 Location w/Service Location Names, Bill Payer w/Bill 

suite, and sending the report request to client connections on Payer Names, 8XX Number, City, State/Province, Number- 

a well-known port number on the designated host machine. ing Plan Area (NPA), NXX (Exchange code where N=2-9 

As shown in FIG. 7, interface socket connections 264, 266 and X=0-9), and Country Code. 

are shown interfacing with respective back end servers 400 A common database is maintained to hold the common 

and 500. In the case of priced billing data from a StarODS 50 configuration data which can be used by the GUI applica- 

fulfilling server 400, report requests are published by the RS tions and by the mid-range servers. Such common data will 

server 260 to a pre-defined subject on the Talarian Server. include but not be limited to: customer security profiles, 

When handling other incoming messages published by back billing hierarchies for each customer, general reference data 

end servers using Talarian SmartSockets 4.0, another dae- (states, NPAs, Country codes), and customer specific pick 

mon process is provided that uses Talarian C++ objects to 55 fists: e.g., ANIs, calling cards, etc. 

connect their message queue and extract all messages for a With regard to the front-end client GUI components, the 

given subject for storage in a database table included in above-mentioned Inbox client application 210 functions as 

database 263. Each message includes the track number of an interface between the client software and the Inbox server 

the report that was requested from the fulfilling server. 270 for presenting to the customer the various type of reports 

From the report scheduler interface, the user may specify 60 and messages received at the Inbox including all completed 

the type of reporting, including an indication of the sched- reports, call detail, alarms, and news. Preferably, the mes- 

uling for the report, e.g., hourly, daily, weekly or monthly. sages for the user in the inbox is sorted by type (e.g., report, 

For priced data the user has the option of daily, weekly, or call detail, alarms) and then by report type, report name, 

monthly. For real-time, or unpriced data, the user has the date, and time. A more detailed description of the StarWRS 

option of hourly, daily, weekly or monthly. The report 65 Inbox Server component may be found in commonly- 

scheduler interface additionally enables a user to specify a owned, co-pending U.S. patent application Ser. No. 09/159, 

page or E-mail account so that a respective page or e-mail 512, entitled MULTI-THREADED WEB BASED USER 
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IN-BOX FOR REPORT MANAGEMENT, the contents and and chart types, or both types simultaneously. The spread- 
disclosure of which is incorporated by reference as if fully sheet presentation allows for sorting by any arbitrary set of 
set forth herein. columns. The report viewer 215 is launched from the inbox 

Particularly, the Inbox client application uses the services client 210 when a report is selected and may also be 

of the backplane (FIG. 3) to launch other applications as 5 hunched from the inbox when a report is selected, 

needed to process report messages. The inbox will also use By associating each set of report data which is uploaded 

the services of the data export objects to provide a save/load from mc Inbox 2 70 with a "metadata" report descrip- 

feature for inbox messages, and, is used to provide a don object> te may be prescnted a report . 

user-interface for software upgrade/download control. Inbox dfic prcsentation code . At one kveL metadata descrip . 

messages are generated by the versioning services of the 1Q ^ ^ ^ ^ [n a ^ 

backplane; actual downloads will be accomplished by a des each fow a ^ from ^ 

request through the inbox. . j j « *■ c t cui u 

In the preferred embodiment, the inbox client receives * cr 35 an ordercd coUection of columns Each column has a 

information on multiple threads to allow a high priority ^ata a ™™> aod a de ^ d dls P 1 ^ . forma r etc * Col ™° 

message to get through even if large download is in progress. descriptive information will be stored in an object, and the 

Typically, the browser is configured to allow more than one 15 entlf e rcsult ^ be described by a list of these objects, 

network connection simultaneously, i.e., the polling thread one for each column, to allow for a standard viewer to 

on the client uses a separate connection to check for new present the result set, with labeled columns. Nesting these 

messages, and start a new thread on a new connection when descriptions within one another allows for breaks and sub- 

a new message was detected. In this way, multiple messages totaling at an arbitrary number of levels. The same metadata 

may be downloaded simultaneously. 20 descriptions may be used to provide common data export 

The Report Requester application 212 is a GUI Applet and report printing services. When extended to describe 

enabling user interaction for managing reports and particu- aggregation levels of data within reporting dimensions, it 

larly includes processes supporting: the creation, deletion, may be used for generic rollup/drilldown spreadsheets with 

and editing of the user's reports; the retrieval and display of "just -in-time" data access. 

selected reports; the display of selected option data; and the 25 The metadata data type may include geographic or 

determination of entitlements which is the logical process telecommunications-specific information, e.g., states or 

defining what functionality a user can perform on StarWRS. NPAs. The report viewer may detect these data types and 

In the preferred embodiment, a Report request may be provide a geographic view as one of the graph/chart types, 

executed immediately, periodically, or as "one-shots" to be Referring now to FIG. 8, there is shown the high-level 

performed at a later time. As described herein, the report 30 logical approach of the StarODS data management system 

scheduler service maintains a list of requested reports for a 400 integrated with the StarWRS component 200 of the 

given user, and forward actual report requests to the appro- nMCI Interact architecture. Generally, the data management 

priate middle-tier servers at the appropriate time. Additional system 400 of the invention, referred to herein as 

functionality is provided to enable customers to manage "StarODS", provides customers with priced reporting data 

there inventory, e.g., reschedule, change, or cancel (delete) 35 pertaining to telecommunications services. Although the 

report requests. description herein pertains to priced billing data, it should be 

The Report Viewer application 215 is a GUI Applet understood that the principles described herein could apply 
enabling a user to analyze and display the data and reports to any type of reporting data. Through StarWRS web-based 
supplied from the StarODS fulfilling system 400. reporting, the StarODS system provides priced reporting 
Particularly, the Report Manager 250 includes and provides 40 data and implements a DataMart approach for maintaining 
access to the metadata which is used to tell the Report the data used for customer reporting. StarODS stores and 
Requestor what a standard report should look like and the incrementally processes customer's priced data included in 
"pick-list" options the user has in order for them to custom- call detail records, and loads this processed data in Data 
ize the standard report. It is used to tell the Report Viewer Marts in a manner such as described in commonly owned, 
client how to display the report, what calculations or trans- 45 co-pending U.S. patent application Ser. No. 09/159,402, 
lations need to be performed at the time of display, and what entitled DATA WAREHOUSING INFRASTRUCTURE 
further customization options the user has while viewing the FOR WEB -BASED REPORTING TOOL, the contents and 
report. It additionally includes a common report view by disclosure of which are incorporated by reference as if fully 
executing a GUI applet that is used for the display and set forth herein. From these data marts customer's priced 
graphing of report data and particularly, is provided with 50 reporting data may be provided to customers on a daily basis 
spreadsheet management functionality that defines what via the StarWRS reporting system, 
operations can be performed on the spreadsheet including For priced reporting data, report categories from which a 
the moving of columns, column hiding, column and row variety of reports can be generated include: a) Financial 
single and multiple selection, import and export of spread- category — for providing priced data reports relating to long- 
sheet data, and printing of spreadsheet, etc. It is also 55 est calls, most expensive calls, Off Peak Calls, payphone 
provided with report data management functionality by report, usage summary, calling card summary, and area code 
defining what operations can be performed on the data summary for Toll Free, VNET, Vision, and CVNS custom- 
displayed in a spreadsheet including dynamic operations as ers; b) Marketing category — for providing priced data 
sorting of report data, sub-totaling of report data, etc. reports relating to country code summary, state summary, 
Furthermore, the report viewer 215 interprets metadata; and, 60 frequent numbers, frequent area code summary, frequent 
communicates with the Backplane (FIG. 4). The report state, and frequent cities; c) Telecommunications category — 
viewer application 215 additionally accepts messages telling for providing priced data reports relating to call duration 
it to display an image or text that may be passed by one of summary, IDACC/Supp Code Summary and Call Access 
the applications in lieu of report data (e.g., Invoice, Broad- Summary for Toll Free, VNET, Vision, CVNS customers; d) 
band report, etc.) 65 Call Center report category — for providing priced data 

All reporting is provided through the Report Viewer reports relating to most active toll free numbers, Hourly 

interface which supports spreadsheet, a variety of graphic Distribution, Day of Week Distributions, state summary, and 
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country code summary for their Toll Free, VNET, Vision, highly current data, typically at least 72 hours old. In 

CVNS customers; e) Monitor Usage — for providing priced accordance with customer- reporting needs, data marts 470 

data reports relating to longest calls, most expensive calls, are partitioned in accordance with partitioning schemes 

most active calling card and most active toll free numbers which, in the invention, is based on customer-ID. 

for their Toll Free, VNET, Vision, CVNS customers; f) 5 Particularly, each DataMart is engineered for servicing spe- 

Analyze Traffic — area code summary, country code cific customers or specific product sets, as well as engi- 

summary, state summary, range summary, city summary, neered for the specific requirements of the customer/product 

frequent numbers, payphone report, usage summary, calling such as high insert activity, heavy reporting requirements, 

card summary, IDACC/Supp Code Summary, Day of Week etc. As data is volatile and changing and may not produce 

Distributions, Hourly Distribution, Call Access Summary 10 consistent results for the same query launched at multiple 

and review calls; and, a g) Check Calling Frequencies times, ODS is engineered for high performance through 

category — for reporting on frequent numbers, frequent area appropriate storage technologies and parallel processing, 

code, frequent country codes, frequent state and frequent Although not shown, a common data warehouse is provided 

cities. in this ODS layer that is responsible for performing storage, 

FIG. 8 illustrates the primary components implemented in 15 retrieval and archiving of data, typically of relaxed currency 
the StarODS priced reporting data management component (e.g., more than 24 hours) and is targeted at trend analysis 
400. As shown in FIG. 8, a first traffic feed 405 provides raw and detection. In the preferred embodiment, the datamarts 
call detail records from external network switches, translates utilize an Informix database in a star topology, 
and sorts the data into billable records for input into two Particularly, as illustrated in FIG. 9, the data model 459 is 
systems: a Commercial Billing system ("NCBS") main- 20 one component comprising the priced reporting data store, 
frame server process 410 for pricing the records at tariff for In the preferred embodiment, the data model of StarODS is 
customers subscribing to, e.g., MCI's VNET and Vision a dimensional or "star schema" model, including a central 
telecommunications products; and, a toll-free billing server fact table multiply joined to a number of attendant tables 
process 420 for pricing the records at tariff for customers known as dimensions. The relationships between the fact 
subscribing to toll — free telecommunications products. A 25 table and the dimensional tables are either enforced through 
common data gateway component 430 including a main- keys, which may be generated, or as lookup codes. As shown 
frame extract process 435 and a data harvesting process 440 in FIG. 9, the central fact table 461, referred to herein as 
receives these inputs on both a daily and monthly basis for "Perspective Base," provides access to a collection of 
processing. Particularly, the mainframe extract process 435 attributes or facts concerning a call. The dimensional tables 
creates a selection table including all subscribing customers, 30 include the following: an Access Termination table 462 
compresses files for transmissions and extracts priced comprising data indicating whether a call was charged to 
reporting records from the runstreams. The harvesting pro- recipient (inbound) or originator (outbound); an Access 
cess 440 is responsible for performing data validations, Type table 464 comprising data indicating the type of access 
filtering, data translations, data grouping, data routing, and (for outbound calls) or egress (for inbound calls) character- 
data logging functions. According to a dimension table 35 istics of a call; a Billing Corp table 466 comprising data 
based on data within selected BDRs, the harvesting process indicating the hierarchical status of a customer for the 
applies business rules to the data, cleanses the data, trans- purposes of billing charges for products and features; a Toll 
forms the data, creates load files for DataMarts and com- Free Number table 468 comprising data indicating any 
presses files for storage in the DataMarts. The harvesting dialed number in which the three digits following the 
component 440 may additionally perform an aggregation 40 country code (1 for USA) is currently either 800 or 888; a 
function for supporting long term storage and rapid access of Product Type table 469 comprising data indicating the 
data for customer reporting, and performs trigger actions/ product for which services are bundled for the purpose of 
events based on predefined criteria. invoicing; a GMT table 471 comprising date and time data 

Additionally, as shown in the FIG. 8, other external adjusted to the Greenwich Mean Time Zone; a LST table 

systems and applications may interface with the common 45 473 comprising date and time data adjusted to the local MCI 

data gateway component 430 including: Cyclone Billing switch which permitted access to the MCI network; an 

system 422a and Concert Virtual Network Services 422b Orig_Geo table 476 comprising data indicating the geo- 

which provide additional billing detail records; and, a call- graphic characteristics of a call's origination; a Term_J3eo 

ing area database 425 which provides geographical refer- table 477 comprising data indicating the geographic char- 

ence information, i.e., identify city, state and country infor- 50 acteristics of a call's termination; a Report Geo table 478 

mation. comprising data indicating the geographic characteristics of 

After the data has been processed in the Harvesting a call's origination or termination; an Idacc table 479 

component 440 it is input to an operational data store comprising data indicating a customer's defined id and/or 

component ("ODS") 450 that stores the billing detail records accounting code; a Data Stream table 481 comprising data 

and dimension tables as a data model. This ODS layer 450 55 relating to the line speed characteristics of a data (non- voice) 

is comprised of all data harvested from all applications in the call; a Pay Phone table 482 comprising data denoting calls 

data harvesting layer 430, and feeds report-supporting Data- originating from a payphone; a Usage table 483 comprising 

Marts 470 in a manner which supports customized data data indicating the geographic attributes of a call which 

access. The Datamarts may be engineered to pre-process affect Tariff rates; an EVS Product table 484 comprising data 

data, create aggregates, and otherwise perform transforma- 60 representing Enhanced Voice Services products; a Directory 

tions on the data prior to DataMart loading 465 in order to Assistance table 486 comprising data indicating those calls 

implement a defined data model, e.g., star schema key requesting Directory assistance; a Range table 487 compris- 

structures, fact and dimension tables depicted as block 460. ing data indicating distance bands a call may fall into; an 

In the preferred embodiment, as shown in FIG. 8, the NCR table 488 indicating Network Call Redirect calls; a 

Operational Data Store 450 includes multiple datamarts 470 65 Cell Phone table 489 comprising cellular call characteristics 

each for storing and retrieving daily and monthly priced data data; a VOS table 491 indicating Voice Operator Services 

on a periodic basis. It primarily is responsible for hosting calls; a Conference Call table 492 having data pertaining to 
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characteristics of conference calls; a Cross Corp table 493 
comprising data indicating inbound cross corporate routing 
of calls; a Currency table 494 indicating unit of currency for 
call prices; a card table 496 comprising data for billing calls 
to a location that may not be the one which originated the 5 
call an NCT table 497 comprising data representing Net- 
work Call Transfers; an Amount Range table 498 indicating 
call usage ranges based upon amounts; and, a Duration 
Range table 499 indicating call usage durations based on 
amounts. This star schema model is optimized for decision 10 
support and the retrieval of large amounts of data. Appendix 
H provides the data attributes of each of these dimension 
tables. As known, in the dimensional model, the grain of 
data stored in the fact table determines what level of data can 
be drilled down into. It should be understood that the grain 15 
of the data stored in the Perspective Base table is at the 
singular call level. 

As described herein, from the data included in these data 
marts, one-time or recurring priced data reports are available 
for reporting through the NMCI Interact StarWRS reporting 20 
system 200. 

Additionally, referring back to FIG. 8 there is provided a 
Decision Support Server ("DSS") reporting engine compo- 
nent 475 that performs the following functions: 1) receives 
various customer report requests from the StarWRS GUI 25 
Report Requestor component and accordingly generates 
database queries; 2) routes the query to the appropriate data 
marts 470, data warehouse or operational data store; and, 3) 
responds to the requestor with a formatted result set. The 
DSS server 475 may also perform cost estimation, agent 30 
scheduling, workflow broadcasting interface, and transac- 
tion logging functions. In the preferred embodiment, the 
DSS 475 is a cluster of DEC (Digital Equipment Corp.) 
UNIX 8400 servers running Information Advantage® soft- 
ware accessing an Informix database, e.g., Informix 35 
Dynamic Server V.7.3. database product, distributed across 
multiple Data Marts. 

In accordance with the invention, the primary function of 
the DSS 475 is to generate priced billing report data in 
accordance with the customer's request which is received 40 
from the StarWRS reporting component as a metadata 
message. To accomplish this, the DSS interfaces with two 
StarWRS systems: Report Manager 250, and Inbox 270, as 
shown in FIG. 8. The Report Manager/Scheduler formats the 
customer's request in accordance with a defined set of rules 45 
and sends a metadata request message to the DSS. The DSS 
475 reads the customer's metadata descriptions of the type 
of priced data report requested by a customer, translates the 
metadata into database queries, and implements commercial 
off-the-shelf ("COTS") tools such as Information Advan- 50 
tage's Decision Suite™ to generate SQL queries, and run the 
queries against the data in the DataMarts. Afterwards, the 
query results are formatted by a formatter process into a 
form readable by StarWRS report viewing components, and 
the completed reports are transmitted to the directory of the 55 
customer's Inbox, e.g., via FTP. 

In the preferred embodiment, a publish-and-subscribe 
communications tool such as Talarian SmartSockets™ mes- 
saging middleware is used to coordinate report requests 
transmitted from the StarWRS report Manager to DSS, and 60 
report completion notification from DSS to the StarWRS 
Report Manager. The Report Manager formats the custom- 
er's request in accordance to a defined set of rules and sends 
the request to the DSS as a Talarian message with the Report 
Manager 250 maintaining the Talarian Sender program, and 65 
the Decision Support Server 475 maintaining the Talarian 
Receiver program. Messages are sent with guaranteed mes- 
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sage delivery ("GMD"), thus assuring all request data sent 
by RM is received by the DSS. As known, Talarian mes- 
saging middleware defines a message as types and subjects. 
A message type is a structure that defines the format of the 
message. Message subjects are subsets of message types and 
describe messages by which Talarian receivers can sub- 
scribe. Conversely, message subjects describe messages by 
which Talarian senders publish. 

As depicted in greater detail in FIG. 10(a), a Report 
Manager/DSS application programming interface "API" 
480 is provided whereby the RM server 250 publishes the 
message to the Decision ^Suppo^t Server in response to its 
receipt of a report request. Subsequently, the DSS 475 
returns a "Message Received" message. When the DSS has 
processed the request, it publishes the message to the RM 
250 with the name and location of the report file or an error 
message to the Report Manager, via an "NRL" metadata 
message as described herein. 

FIG. 10(b) illustrates an DSS/Report Manager application 
programming interface "API" 485. In the preferred 
embodiment, all return messages are persistent. Thus, as 
shown in FIG. 8 the DSS incorporates a Talarian message 
queue 490 operating on a First-In-First-Out (FIFO) basis. If 
the DSS is unable to establish the connection with Talarian, 
or there is an error in transmission, the DSS queues all 
messages, and continues to retry until a successful send is 
executed. 

Similarly, a DSS/Inbox API is provided to manage FTP 
file transmissions including: error handling, retry logic, and 
the ability to maintain the file name and location of where 
report files are stored. Particularly, the DSS/Inbox API sends 
the report file to the inbox (FIG. 8). If the DSS has generated 
an error condition, and the report is unable to be generated, 
an error message will be sent to the inbox in place of the 
report file. In either case, a return message will be delivered 
to the DSS/Report Manager API 485 indicating a successful 
or unsuccessful generation and transmission of the report 
file. 

More particularly, as shown in FIG. 12(a), an RTServer 
process 377 is provided for maintaining connections, ensur- 
ing guaranteed message delivery, and tracking the success of 
all messaging operations. As the Report Manager interfaces 
with multiple systems, the RTServer 377 processes are 
located in the RM. The DSS is provided with RTClient 
processes 377a, b that provides the API to RTServer: one 
RTClient 377a for providing the API to Report Manager for 
receiving messages; and, a second RTClient 377£> for pro- 
viding the API for the NRL. However, it should be under- 
stood that other ODS boxes can have one RTClient. The RM 
and Arbitrators 3 60a, 6 use the GMD feature of Talarian to 
deliver messages. RM/Inbox communication is not affected 
by outages of ODS server as the arbitrator and ODS com- 
munication is independent of RM/Inbox communication. 

In the preferred embodiment, the DSS architecture is 
transparent to the Report Manager which publishes Talarian 
messages to which the DSS will subscribe. In addition to the 
tokenized character string request message which specifies 
report type, filters, and any customer request-specific 
information, RM server provides additional fields as part of 
the Talarian request message including: a Corp_JD, Priority, 
and RequestlD. Corp__ID allows the DSS to route the 
request to the appropriate data store without having to 
invoke a parser. Data are partitioned on Corp_ID in the 
ODS database warehouse. Request_id is used to send back 
an ARDA failure message, in the event of an invalid 
message. The Priority field allows DSS to pickup the next 
high priority request from a queue of non-processed 
requests, without invoking the parser. 
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FIG. H(b) illustrates the implementation of the COTS the size of the file; "entpid" indicating the Enterprise id 

Information Advantage® Interface Object ("IAIO") 372, which may consist of one or more corporate id's; "userid" 

which is a process running in the DSS 475 for performing which is an identifier assigned to each user of the system; 

the following functions: 1) publishes and subscribes Talarian "stdrptid" which identifies each report and is similar to 

messages to Report Scheduler; 2) parses the request meta- 5 column id's but on the report level; "userptid" which is the 

data ARD (Add Report Definition) message; 3) publishes an user-assigned identifier for a report request; "compress" 

ARDA (Add Report Definition Acknowledgment); 4) popu- having possible values ' r»yes, 'I'oqo indicating if a report 

lates a request table 390 with total, sub- total and sort is to be compressed, e.g., using a standard .zip routine; 

information according to the received report request; 5) "threshold" defining the number of lines that shall appear on 

transforms the ARD tokens from the metadata request into to the report; "totalmode" which defines how the report shall 

an overlay file 392 which is a text file that is submitted to be totaled, subtotaled as indicated by possible values '0'=No 

IA's Decision Suite™ process to generate the corresponding total, No subtotal; 'V-Only Subtotal; '2'^Only Total; '3' = 

SQLs; 6) updates a Request Status table 391 with appropri- Total and Subtotal; "nrLJotals" indicating the formatter to 

ate status, e.g., process complete, failed, in progress, etc.; total the columns specified in the"*, hdr" file. These columns 

and, 7) if a failure occurs, it updates an error log (not 15 are numeric and have a sub to talflag=y in a column id table; 

shown). "format_columns" which define derived columns on which 

More particularly, in view of FIG. 11(6), ARD metadata percentages are to be calculated; "error_code" for indicat- 

request messages are received into the ODS system via ing parser failure or system failure. If it's a parser failure 

arbitrator processes 360a,£> which are responsible for routing condition, the code is returned to Report Manager; "error„ 

the request message to the appropriate ODS database 20 desc" indicating the error description; and, "rpmgr__ 

according to a Corp/ODS mapping table 365. Report Man- columns" which are the columns sent to the DSS by Report 

ager publishes a single message subject "Arbitrator" having Manager. The formatter checks this list against the list in the 

the above-mentioned request, Corp_ID, and Priority field .hdr file. 

information. Report Manager uses a round robin message Similarly, the Request_Status table 391 provided in 

delivery mechanism complemented by Talarian's GMD to 25 Appendix I is populated to include the status of the different 

publish messages to the subject Arbitrator 360a, b. The processes including: "Request__Id," i.e., the unique identi- 

arbitrator extracts the Corp_ID field from the message and fier for the request, "Priority," e.g., having a value of "1," for 

maps the Corp_ID to corresponding ODS DataMart in the example, meaning adhoc; a "timestamp" which is the Infor- 

table 365 it maintains. The arbitrator then republishes the mix Date Time that will be used when two or more messages 

message with the ODS#. As shown in the FIG. 11(6), a 30 have same priority; and "Status" which is a char message 

second arbitrator process 360b is provided to assure fail- including the following status fields: "new_message" indi- 

over capabilities. eating that a new message has arrived, yet to be processed; 

In FIGS. 11(a) and 11(6), a Talarian receiver, referred to "in_IAIO" status indicating that the message is being 

herein as a Talarian Interface Object ("TIO") 370, is a processed by interface process IAIO; "parser_f ailed" status 

process that receives the Talarian message, manages the 35 indicating an Invalid message from RM. NRL process sends 

GMD functionality, and posts updates to the request table a ARDA error message; "parser_success" status indicating 

390 and request status table 391. As shown in FIG. 11(6), the that the message from RM is a valid message, NRL process 

TIO receivers 370 subscribe to a subject "ODS#." The would send a ARDA message to RM; "IAIO_complete" 

receiver inserts the message received from the arbitrator into status indicating that the report has been generated and 

the request table 390 and request status table 391 along with 40 directory and file name fields are modified. Formatter can 

the priority, timestamp and status fields. The request status pick up this message; "LAI 0_f ailed" status indicating that 

table resides on the ODS database and the messages are IAhas failed to generate a report, i.e., an error has occurred 

stored in the queue to provide queuing, log and tolerance generating a report; "in_formatter" status indicating that the 

from the failures. To determine the pending messages to be formatter is converting the text file generated by IA to a 

processed, status field and history_stat flags are used. 45 comma delimited format. The formatter may also, if 

Appendix "I" illustrates the contents of the ODS Request required, does the percent (%) calculations, e.g., subtotals 

table 390 and Request Status tables 391, which are part of etc.; "format_success" status indicating that the formatter 

the ODS database. successfully completed translation of the file. It also popu- 

In the preferred embodiment, the tables provided in lates the inbox file name, inbox file directory, nrltotal 

Appendix I include: an "informix'\request table 390 (FIG. 50 (optional) fields in the table; "format_f ailed" status indi- 

11(a)) which is the table maintained for the purpose of eating that the formatter failed to translate the text file 

holding specific report request information from the generated by IA; "in_ftp". status indicating that the ftp 

received ARD message, and, an "informix".req_status for process is currently sending the file to inbox; "ftp_success" 

holding status of DSS processes for the current request. status indicating that the file generated by formatter is ftp'd 

Hius, for the example ARD message provided in Appen- 55 to inbox; "ftp_f ailed" status indicating that the formatted 

dix I, the request table 390 will be populated to include: a file could not be ftped to inbox; "in_NRL" status indicating 

"request_id," which is the unique identifier for the request; that the NRL process is trying to send either ARDA message 

a "msg_desc " representing a copy of the ARD message; or NRL message to RM; "NRL_sent" status and "ARDA- 

"unique_fhame," which is the unique name assigned to sent" status indicating that the respective NRL or ARDA 

each request to enable tracking of individual report requests 60 message has been sent to RM. Each DSS process updates the 

and is additionally assigned to the report returned to the request status table as it processes, 

report manager; a" report„dir" indicating the location of the A further "history _stat" field may be provided in the 

report that Decision Suite™ generates (which may be a tab request_status table 391 having a value, e.g., 'A' (Active) 

delimited report file); "format__dir" indicating the location indicating that the record needs to be processed, or, indicat- 

where the report formatter generates (comma delimited file); 65 ing 'H' (History), when the record is no longer active and 

"inbox_dir" indicating the location on the Inbox (Report needs to be archived in a separate database set up for 

Manager) where the report is sent; "inbox__fsize" indicating archival purposes (not shown). 
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As further shown in Appendix I, there are two more tables 
that are defined for DSS sorting and formatting processes: a 
Column ID Table, and a Translation table which are tables 
configured for the formatter process, as will be described. 

As further shown in FIG. 11 (b), in operation, each Infor- 
mation Advantage® Interface Object ("IAIO") 372a, b, . . . 
n reads the status table 391 for new entries. When a new 
entry is posted, it invokes a parser process 393, and invokes 
the Information Advantage® SQL generator engine which 
retrieves the requested data from the database, and updates 
the status table 391. 

Particularly, the Decision Suite™ tool receives the over- 
lay file (FIG. 11(a)) and performs the following functions: 1) 
generates SQL; 2) submits the SQL to the appropriate 
datamart (ODS database); 3) generates a Report file with a 
*.txt extension; 4) updates Request Status table 391 with 
appropriate status; and, 5) if a failure occurs, updates the 
error log. Following generation of the *txt file, a sort process 
is invoked to perform the following functions: 1) reads the 
Request table 390 for column(s) on which to sort the Report; 

2) reads the *.txt file; 3) sorts the *. txt file and generates two 
files: i. a file with a *.hdr extension which file contains the 
header information, consisting only of only column id's, 
and, ii. a file with a *.data extension which file contains 
sorted data provided in the * .txt file and is the body of the 
Report; 4) it further updates the request status table with a 
' success' or ' failure' code; and, 5) if a failure occurs, updates 
the error log. 

As further shown in FIG. 11(6), continuously running 
KIP, NRL and ARDA processes are provided to take appro- 
priate actions in accordance with the request status table 
entries. For example, an FTP process 378 performs the 
following functions: 1) reads the status table 391 for entries 
ready to be sent to the Inbox and FTP's the .csv or .txt to the 
inbox 270; 2) Determines success or failure of file transfer; 

3) Updates the Request Status table 391; and, if a failure 
occurs, updates an error log. 

The NRL (Notification of Report Location) process 382 
performs the following functions: 1) reads the Request 
Status table 391 for any success status or failure of any 
process; 2) Invokes a receiver process with appropriate 
status and file location populated in the NRL; and, 3) If 
failure occurs, updates the error log. Particularly, should an 
error occur in any of the DSS processes, an error log is 
updated. Error log directories may be delineated by process 
and day of week. Each new error generated by the same 
process in the same day appends the log with the new 
message. In either event, the NRL process returns the NRL 
message to Report manager indicating the status and loca- 
tion of any generated files. 

As further shown in FIG. 11(6), an ARDA process 383 
reads the status table 391 for parser failures. Should the 
parser fail due to insufficient or missing data, ARDA process 
will return an ARDA message to the Report Manager with 
the appropriate error code. In particular, the types of con- 
ditions that result in error messages being sent to the report 
manager and/or local log include: i) when the request 
message received from the Report Manager can not be 
parsed due to bad data or invalid format; ii) when the SQL 
can not be generated due to invalid request format or 
parameters; iii) system or process failure; iv) cannot query 
database due to a database failure; etc. 

For Priced Reporting, the StarWRS report requestor func- 
tionality is invoked as described in above -referenced, 
co-pending U.S. patent application Ser. No. 09A59,4O9. 
Particularly, the end-to-end process 600 from a priced report 
request to report delivery is shown in FIGS. 13(a)-13(c) . 
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Specifically, a user first establishes communication with the 
DMZ Web server 44 and logs on to the nMCI Interact system 
by entering the user's name and password onto a logon 
dialog box. Then, an application running on the backplane 
5 directs a "Validate User Message" common object to the 
StarOE server 280 via the web server and dispatcher servers 
(FIG. 3) to direct the StarOE server 280 to perform security 
validation and authenticate the user ID and password in the 
manner as described in commonly owned, co-pending U.S. 
patent application Ser. No. 09/159,514, now allowed, 
entitled AUTHENTICATION AND ENTITLEMENT OF 
WEB BASED DATA MANAGEMENT PROGRAMS, the 
contents and disclosure of which is incorporated by refer- 
ence herein. It is understood that all communication to the 
StarOE server is via TCP/IP with a Unix process listening on 

15 a known TCP port. The StarOE server acts as a proxy when 
messages are sent from the Dispatcher server 46 and sup- 
. ports synchronous transactions. All data and security infor- 
mation is accessed by direct queries to a StarOE server 
database 283, such as provided by Informix. Once a user is 

20 logged on, the Web Server 44 (FIGS. 3 and 7) requests a 
current list of authorized applications from the StarOE 
server 285. Particularly, as described in co-pending U.S. 
patent application Ser. No. 09A5 9,408, the contents and 
disclosure of which is incorporated by reference herein, a 

25 "Get User Application Request" message is communicated 
to the StarOE server via the backplane from the report 
requester which queries the Informix database to obtain a list 
of authorized applications, i.e., services, for the user and 
which determines which buttons on the home page are 

30 active, thus controlling their access to products. This infor- 
mation is downloaded by a GUI applet that is executed via 
the Backplane (FIG. 4) and incorporated into the home page 
that is presented to the user. An exemplary home page screen 
display 80 is shown in FIG. 5 which provides a list of icons 

35 70 representing the possible options available to the user 
according to that customer's entitlements. 

Appendix H of co-pending U.S. patent application Ser, 
No. 09/159,409 provides the format and content of the nMCI 
Interact common objects downloaded to the Report 

40 Requestor client application to enable web-based reporting. 
As shown in above -referenced Appendix H, the Report 
Requestor first asks for common objects for a user's default 
timezone, language and currency. The Report Requestor 
objects are invoked to retrieve from StarOE the various 

45 customer entitlements relating to security, geographical 
hierarchy, billing hierarchy, and paging and e-mail 
notification, as further shown in Appendix H. 

In response to selection of the Report Requestor icon, a 
display is generated to present the reporting options to a user 

50 in accordance with that user's entitlements as previously 
determined. It should be understood that in the preferred 
embodiment, the icons for applications the user has security 
access to are shown bolded. Thus, for a customer subscrib- 
ing to nMCI Interact Priced Reporting, a Priced Reporting 

55 icon is automatically enabled when the home page appears. 
Thus, upon selection of a Report Requestor icon 76 from 
the home page screen display 80 of FIG. 5, a StarWRS 
report requestor web page is presented to the customer. The 
backplane object allows the user access to the Report 

60 Requestor front end if the user is so authorized, and a client 
priced reporting application is downloaded to the customer 
who is presented with the Priced reporting dialog screen (not 
shown), as indicated at step 602 in FIG. 13(a). It is from this 
screen that the user is presented with priced reporting 

65 options to view/retrieve completed reports via the StarWRS 
Inbox, or create a new report or, modify an existing Priced 
call detail data report. 
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Particularly, from the Priced reporting dialog screen, the 
user is enabled to edit an existing report maintained in the 
report manager inventory, generate a new report, copy an 
existing report, or delete an existing report For example, as 
indicated at step 605 (FIG. 13(a)), a user may initiate 5 
retrieval of the user report list containing existing user 
reports from the RM inventory, which process entails invok- 
ing the Report Requestor to initiate generation of a metadata 
request to download the report inventory from RM as 
indicated at step 610. The Report inventory for the specific 10 
user is loaded and displayed for the user on the user report 
request display screen, enabling the user to select a report, 
as indicated at step 612. Then, at step 615, the selected report 
is retrieved from StarWRS Report Manager and displayed 
for the customer. 15 

Then, as indicated at steps 618 and 620, the customer may 
enter the desired reporting options and reporting criteria 
including: 1) the report product including toll-free, MCI 
Vision, and MCI Vnet options; 2) the report category which 
includes options for: analyzing traffic, call center, call detail, 20 
checking calling frequencies, financial, marketing, monitor- 
ing usage, and telecommunications categories for toll-free, 
Vnet and Vision customers; 3) the report type which 
includes priced call detail data or traffic data options; and 4) 
a report direction and which includes inbound, outbound, or 25 
both directions. Additionally, the user may select the report 
format associated with a reporting category. 

Whether creating a new report or editing an existing 
report, the user is enabled to select customization options 
from successive dialog screens (not shown) that are pre- 30 
sented to the user showing all the report customization 
categories for building a new report and/or editing an 
existing report. From this screen and related report building 
dialog boxes, all of the initial values for retrieving the 
MetaData, customization options and GUI builder options 35 
from the report manager server 250 necessary to build (edit) 
a report are provided in accordance with the user's entitle- 
ments. As described in greater detail in co-pending U.S. 
patent application Ser. No. 09/159,409, a user may provide 
the following customization and report builder options: 40 
general customization options; layout customization 
options; access customization options; hierarchy customiza- 
tion options; geographic customization options; and, notifi- 
cation customization options. 

In performing the report request process, as shown in FIG. 45 
7, the Report Requestor client application 212 gains access 
to the Metadata stored at the Report Manager server 250 
through messaging, as indicated at step 625. Particularly, as 
hereinafter described, a message generated by the Report 
Requestor in accordance with the user request is first 50 
received by the report manager proxy 250'. In the preferred 
embodiment, the report manager proxy comprises a set of 
tools in the form of reusable objects, preferably written in 
C++ code, or the like. For example, a parser object tool is 
employed. to decompose the Metadata messages sent by the 55 
report requester 212 to validate the message. If errors are 
found in the Metadata input, the RM will return an error 
message to the requesting client. If the Metadata passes the 
validation tests, the request type is then determined and the 
appropriate service will be invoked after which a standard 60 
response is sent back to the requesting client or and/or 
fulfilling server. 

Hie Report Manager 250 implements stored procedures to 
translate the message, perform the request, and send the 
information back to the Report Requestor 212 which uses 65 
the metadata to determine what a standard report should 
look like, the customization options the user has, and the 



types of screens that should be used for the various options 
(i.e., single selection, multiple selections, etc.). It is under- 
stood that the selection of available standard template 
reports is based on the user's entitlements. 

The following list provides the types of requests that may 
be initiated by the Report Requestor 212 and the responses 
performed by the Report Manager 250: 1) Get/Send report 
template list (GRTL/SRTL) — which request retrieves the list 
of all standard report templates for all products and is used 
only to obtain general report information, e.g., report title, 
description, etc.; 2) Get/Send report template detail (GRTD/ 
SRTD) — which request retrieves the details of a specific 
standard report template; 3) Get/Send user report list 
(GURL/SURL) — which request retrieves the list of all user 
reports for the report format selected from a user report table 
and is used only as a request for general report information, 
e.g., report title, status, etc.; 4) Get/Send user report detail 
(GURD/SURD) — which request retrieves the details of a 
specific user's report; 5) Add report definition/ 
Acknowledgment (ARD/ARDA) — which requests addition 
of a user-created report to a user report table. If the report is 
a scheduled report, this request is also communicated to the 
fulfilling server at the time the report is due; 6) Delete report 
definition/Acknowledgment (DRD/DRDA) — which request 
deletes a user-created report from the user table; 7) Copy 
report definition/Acknowledgment (CRD/CRDA)— which 
request creates a duplication of the report the user is editing 
(other than the report title) and creates a new report ID for 
it; 8) Update Reporting Schedule/Acknowledgment (URS/ 
URSA) — which request updates the scheduling information 
on a report without having to send a Delete and Add request; 
and, 9) Get Pick List/Acknowledgment (GPL/GPLA) — 
which request enables the Report Requestor 212 to get a pick 
list provided by StarOE server. 

In a preferred embodiment, as shown in Table 1, the 
interface message sent to the RM server 250 from the report 
requester via the Dispatcher server 46 comprises a three to 
four character message acronym followed by request spe- 
cific parameters. 

TABLE 1 



Parameter 


Parameter 




Acceptable 


Name 


Type 


Required 


Value 


Request 


3 or 4 


Yes 


Msg acronym 




Characters 






Data 


Characters 


No 




parms . . . 








Table 2 illustrates the interface message format returned 


by the RM server 250. 








TABLE 2 




Parameter 


Parameter 




Acceptable 


Name 


Type 


Required 


Value 


Response 


Char (4) 


Yes 


Msg acronym 


Error Code 


Char (4) 


Yes 


0 = OK or 








error 


Data 


Char# 


No 




parms . . . 









As shown in Table 2, the response message to be returned 
in Metadata format preferably includes a four character 
message acronym followed by an error code. A successful 
request (or a request acknowledgment) generates a response 
with an error code of "0". Additional data specific to the 
response follows this error code. If any server receives a 
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message which is not known, the response message will 
echo the message acronym back along with an appropriate 
error code. 

Appendix A provides a series of tables containing the 
content for each metadata message request that can be sent 5 
by the report requester 212 for each of the enumerated user 
requests, in addition to the content of the corresponding 
metadata message responses by the RM server 250. As an 
example, when a user requests a list of all standard report 
templates that can be created for a specified product, jq 
category, and product type, e.g., toll free unpriced data, an 
example metadata format is as follows: 

GRTL<PRODUCT-V,DATATYPE-R,DArACAT-P,IO- 
0> 

where GRTL is the message name, the PRODUCT indicates 15 
the product type, e.g., V-Vnet, C-CVNS, S-Vision, T-toll 
free, F-Traffic view, etc. DATATYPE indicates the data 
type, e.g. R-reports, D-call detail, etc., and DATACAT 
represents the report category, e.g., P-priced, U-unpriced. 

In the hereinafter described manner, the GRTL message is 20 
received by the StarWRS proxy server application 250' to 
enable the RM server 250 to perform the query into the RM 
Informix database having the data associated with the 
request. Specifically, after selecting the Report Requester 
from the browser or the Toolbar, a WRSApp object is 25 
launched. At its creation, the WRSApp object creates a 
DataManager object to guide the data and which initiates a 
CommunicationManager object to manage all communica- 
tion between the client and the server. The Communication- 
Manager utilizes a RptManagerMsg object to create: 1) a 30 
GRTL; 2) a WRSCommWrapper for direct communication 
with the backend; and, 3) a WRSReportManagerUtilParser 
to format the data returned. In response, the Report Manager 
creates a Dispatcher object, which contains the business 
logic for handling metadata messages at the back-end and 35 
utilizes the services of a RMParser class. Upon determining 
that the client has sent a valid message, the appropriate 
member function is invoked to service the request. Upon 
receiving the message, the Report Manager creates the 
Parser object (RMParser) which takes the message apart and 40 
invokes a validation object which validates the message. 

In response to the GRTL message, the data returned by the 
Report Manager server 250 for this particular request may 
include the following data in metadata format as follows: 
SRTL<ERROR=0, REPORTS « <RptCategoryDescrip- 45 
tionl = <RptTitlel.l, RptTemplatelDl .1, 
RptCategoryTypel.l>, <RptTitlel . 2 , 
RptTemplateID1.2, RptCategoryTypel.2», <RptCat- 
egoryDescription2 «<RptTitle2.1, RptTemplateID21 f 
RptCategoryType2.1>, <RptTitle2 . 2 , 50 
RptTemplateID2.2, RptCategoryTVpe2.2 », . . . 
<Rp t Ca te goryDe scrip ti on #n = <RptTitle#n.n, 
RptTemplateID#n.n, RptCategoryType#n.n>, 
<RptTitle#n.n, RptTemplateID#n. n, 

RptCategoryType#n.n>» 55 
wherein RptID# indicates a standard report template ID, 
RptTitle# indicates the standard report template title, Rpt- 
Category# indicates the report category, e.g. Monitor Usage, 
Analysis Traffic, Historical, Executive Summary, Call 
Detail, etc.; and, RptDescript indicates the standard report 60 
template description displayed to the user. Thus, for each 
Report Template Category, there will be the list of reports 
with each entry containing a Report Template Title, a Report 
Template Description and the Report Template ID. 

The SRTL message is sent from the StarWRS RM proxy 65 
server to the report requestor for presentation to the cus- 
tomer. Specifically, the SRTL response is built inside the 



esql wrapper function after obtaining the necessary infor- 
mation through the stored procedure from the Report Man- 
ager Informix database. Tne Report Manager creates the 
RMServerSocket object and sends the SRTL message back 
to the client. 

To retrieve details of the standard report template, the 
GRTD request message request is sent having content shown 
in the table in Appendix A. When specified, the Report ID 
field indicates an existing report that a user may wish to edit. 

Hie SRTD response generated by the RM server is 
formatted in metadata as follows: 

< Report Template ID-ID#, 

NODEl=<node levell, label valuel, assigned unique 

screen identification!, >, 
NODE2-<node leveO, label value2, assigned unique 
screen identification, <control ID2.1, field value2.1, 
data location2.1>, <control ID2.2, field value2.2, data 
location2.2>, <..,..,..», 
NODE#n=<node level#n, label value#n, assigned unique 
screen identification^, <control ID#n.l, field 
value#n.l, data location#n.l>, <control ID#n.2, field 
value#n.2, data location#n.2» 
In the SRTD message, the MetaTreeData Label fields 
include such values as General, Report Name, Report 
Description, Scheduled Execution, etc. The MetaCtrllnfo 
MetaField Value fields may be blank or may contain the 
selection options available to the user. This information is 
taken from the report template database. 

As another example, when a report request is submitted to 
retrieve a full list of user created reports from a user report 
table, i.e., a template list for a particular report product, 
category, and type, the example metadata format is as 
follows: 

GURL<USERID=jeanvnet2,RPTTMPID=l,ENTPID= 
00022924,PRODUCT =T,DATACAT=U> 
with UserlD and ReportTemplatelD fields specified. 
Specifically, this process entails invoking the Communica- 
tion Manager object to communicate with the RM server in 
order to obtain a SURL metadata message. The Communi- 
cationManager utilizes the RptManagerMsg object to create: 
1) a GURL, 2) a WRSCommWrapper for direct communi- 
cation with the backend, and, 3) a WRSReportManagerUtil- 
Parser to format the data returned. The parser returns a hash 
table containing the User Report List. At the RM server, the 
Report Manager creates an Dispatcher object that contains 
the business logic for handling metadata messages at the 
back-end and utilizes the services of the RMParser class. 
Upon determining that the client has sent a valid message, 
the appropriate member function is invoked to service the 
request. The Report Manager, upon receiving a message, 
creates a Parser object (RMParser) which takes the message 
apart and invokes a validation object which validates the 
message. 

In response to the GURL request, the data returned is 
taken from a user report table in the RM server database. The 
generic SURL message in Metadata format returned by the 
RM server 250 includes the following information: 
REPORTS - <UserRptCategoryl * <UserRptTitlel, 
UserRptlDl, activeflag, report type, statusdate », 
<UserRptCategory2 = <UserRptTitle2, UserRptID2, 
activeflag, report type, statusdate>>, . . . 
<UserRptCategory#n = <UserRptTitle#n, 
UserRptlD/m, activeflag, report type, starusdate»> 
wherein for each user report category, there is a list of 
reports where each entry contains a UserRptID# indicating 
a user-defined report template ID, a UserRptTitle# indicat- 
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ing the user's report template title, and a UserRptCategory# ARD<USERID=jeanvnet2,ENTPID = 00022924, 

indicating the user report category. Specifically, the SURL STDRPTID=90,NAME=Ci ty Summary Outbound, 

response is built inside an esql wrapper function after PRODUCT =S, CATEGORY** Analyze Traffic, 

obtaining the necessary information through a stored pro- THRESHOLD=<RECCOUNT=20>,SCHEDULE= 

cedure from the Informix database. The Report Manager 5 A<STARTol99806020000,EN D=199807151200>, 

creates the RMServerSocket object and sends the SURL RANGETYPE=l,SCHEDTYPE=A,TIMEZONE=45, 

message back to the client. BILL ING=INBOUND« 90000003 ,90000003><NA, 

To retrieve the details of a specific user's report, the NAxNA,NA»INBOUND«9 0000004, 

GURD message is sent having data as contained in the table 90000004><NA,NA><NA,NA»,CARDNO = 

shown in Appendix A Specifically when the user selects a <6 5465 4 *~5465465 4654 65465 >,I DAC- 

report from the Inventory List on the Report Requestor a <46546546*~1246>,GEO-GEO<<001,001USA/ 

Communication Manager object is invoked to communicate , ,7X « 7* ^ ~ ~ w . vr . » T ; r; ' . \Z . 

with the RM server & order to obtain a SURD metadata WORLD ZONEl><NA,NA><NA,NA><NA, 

message. The CommunicationManager object first utilizes NA><NA,NA>>GEO <<001 ,001 USA/ 

the RptManagerMsg object to create: 1) a GURD metadata WORLDZONElxCO,COxNA,NAxNA, 

message, 2) a WRSCommWrapper for direct communica- 15 NA><NA,NA»,0 ACCESS- <4~l>,ODISTRANGE» 

tion with the backend, and 3) the RSReportManagerUtil- <A~F>,OUS AGE=<5~4>,SORTBY«<54D>, 

Parser to format the data returned. The parser organizes the DESCRIPTIO N=This report summarizes call detail by 

data into a series of nodes which are utilized to create the the terminating city and state (USA) / province (CA). 

report builder tree on the report requestor customization The report is based on the date/time ranges and report 

screen. Later this data will be extracted from the node and 20 criteria selected. ^COLUMNS- 

used to construct the screen related to the node. The Report <54~55~67~62~36~61~58~63~64~66~65>,ACT 

Manager server creates the MCIDispatcher object which IVE=1 ,TOTALMODE=0,EMAIL=0,PAGE = 0, 

contains the business logic for handling metadata messages LANG=1234, CURR=2345> 

at the back-end and utilizes the services of the RMParser i a this example, the "NAME" field refers to the Report 
class. Upon determining that the client has sent a valid ^ Name ( e g ? city summary ) ; the "PRODUCT" field refers to 
message, the appropriate member function is invoked to the report product (Vision); the "THRESHOLD" field refers 
service the request. The Report Manager, upon receiving a tQ the recofd the "DESCRIPTION" field refers to the 
message, creates the Parser object (RMParser) which takes r t descri tio n; the "COLUMNS" refers to the number of 
the message apart, invokes z .validation object which vali- cohmns ified for a rt b the ^ « BILLING » 
dates the message and builds a response inside the esql 3Q fieM refefS tQ ^ dfied m]iR entitlementj Le<> 
wrapper tunction alter ob aining tne necessary intormation bim merarchy . the "IACCESS" field refers to the inbound 
through the stored procedure from the Informix database ^ ^ {h& « 0ACCESS » refers to the outbcnmd 
.The .Report Manager creates the RMServerSocket object and a ^ «§0RTBY" field indicates the report column 
sends the SURD/SRTD message back to the client. The sorting customization with "A" indicating column(s) having 
responsive SURD metadata message corresponding to a 35 data tQ be sorted in ascendin order m6 » D „ ^tiag 
retrieve user report detail (GURD) request has the following having data to be sorted in descending order; the 
metadata syntax. "SCHEDULE" field referring to the scheduling type, e.g., 
< Report Template ID-ID#, with « A « indicating an ad-hoc report, and the user specified 
NODEl=<node levell, label valuel, assigned unique date range on which to report as indicated by the "START" 
screen identification!, >, 40 and "END" fields, and additionally, the scheduling fre- 
NODE2=<node level2, label value2, assigned unique quency information in the case of a recurring report; the 
screen identification2, <control ID2.1, field value2.1, SUBTOTALCOLUMNS field, referring to the report col- 
data location2.1>, <control ID2.2, field value2.2, data umns having data to be subtotaled; and, the "EMAIL" and 
location2.2>, <. .,..,..», "PAGE" fields indicating reporting notification via e-mail or 
NODE#n=<node level#n, label value#n, assigned unique 45 paging, respectively. 

screen identification^, <control ID#n.l, field Furthermore, for each of the metadata messages in Appen- 

vahie#n.l, data location#n.l>, <control ID#n.2, field dix A, including the Delete Report Definition (DRD), copy 

value#n.2, data location#n.2>, <..,..,..», report definition (CRD), and update report scheduling 

This response thus may include the report information (URS) messages, the report manager server 250 responds to 

having detailed items including: UserReportID (UserlD), 50 the Report Requestor with the processing results. In the case 

User's report name (UserName), product (UserProd), of a copy report, a new User Report ID is assigned and 

Threshold (UserThreshold), User Report Description returned by RM. When editing an existing StarODS (priced 

(UserDescript), Report Columns (UserFields), Report col- call data) report, the user may make changes to the Report 

umn headings (UserHeaders), and, in addition, customiza- Title, the Report Description, the Report scheduling, the 800 

tion options with fields indicating, inter alia, columns to 55 numbers and thresholds, and may customize number of 

display (UserHeaders), user-defined criteria (UserCriteria), rows, report columns, access codes, access types, billing 

a sort order (UserOrder) and scheduling selections location, geographic location, paging notification, and 

(UserSched), the last update of this report (UserLastUpdate) e-mail notification. More specifically, when the user selects 

and, the Report status (if adhoc) (UserStatus), etc. a report from the inventory list or a new report, an WRSEdit 

If a request is made to add a user-created report to a 60 Screen is launched to provide the editing capabilities which 

User_report table maintained by the RM Server 250 and the are available for the report format. WRSedit guides the 

RS server 260, the ARD metadata message having fields screens through the process of retrieving the screens* data, 

defined in the table provided in Appendix A is processed by Some of the screens need data which has not yet been 

the RM server 250, as indicated at step 628, FIG. 13(a). An retrieved, such as 800 numbers or geographic locations, 

example message in metadata format to initiate the addition 65 These screens manage the requests to the DataManager 

of a user-created report for ODS (Inbound/Outbound) object to create the get pick list (GPL) message (Appendix 

reporting data is as follows: A), which launches the CommunicationManager object to 
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perform this task. The CommunicationManager utilizes the in the DSS system. This control process includes logic 

RptManagerMsg object to create the GPL, the WRSCom- enabling the prioritization of report requests and application 

mwrapper for direct communication with the backend, and of rules defining the order in which they should be executed, 

the WRSReportManagerUtilParser to format the data Thus, at the appropriate time, depending on the type or 

returned. In response, the Report Manager server creates the 5 report, reporting period and other parameters, the Informa- 

MCIDispatcher object and invokes the MCIRMParser class. tion Advantage query engine selects the report from the 

Upon determining that the client has sent a valid message, queue, as indicated at step 640, which action is logged in the 

the appropriate member function is invoked to service the report status table (Appendix I) as indicated at step 642. The 

request. The Report Manager, upon receiving a message, SQL statement is then built by Decision Suite™ and routed 

creates the Parser object (RMParser) which takes the mes- 10 to the appropriate data mart for execution in the manner as 

sage apart and a validation object is invoked which validates described herein, as indicated at step 643. The query engine 

the message. The response is built inside the esql wrapper generates the SQL statement from the metadata and executes 

function after obtaining the necessary information through the report which action is logged in the report status table as 

me stored procedure from the Informix database. The Report indicated at step 645. Next, as indicated at step 648, the 

Manager creates the RMServerSocket object and sends the 15 query results are returned, and, a post-SQL formatting 

GPLA message back to the client. process is invoked. 

Having described the functionality of selecting and/or More particularly, as shown in FIG. 12(b), a Formatter 

generating a report and customizing it, reference is now had module 395 may perform various report result transforma- 

to the process for running the report request in StarODS. tions including: 1) Converting of column headers generated 

Particularly, in the preferred embodiment, the user may 20 by Information Advantage® into appropriate column ids that 

select a save and exit report option, or a save and run report are recognizable to the StarWRS client viewer functionality 

option. In either scenario, an WRSEdit object enables a (as indicated at step 650, FIG. 13(fc)); 2) Provide subtotaling 

WRSScnMgr object to save the report to the RM server. The for specific requested "subtotal by" columns in the format 

WRSScnMgr object launches each screens save method required by the StarWRS client interface (as indicated at 

which communicates with the DataManager object to place 25 step 653, (FIG. 13(fc)) and provides report-based totals as 

the screens data in its corresponding WRSNode. Once all of requested by customer, 3) converting binary stream data file 

the WRSNode objects have been updated, the WRSScnMgr to ASCII text file (as indicated at step 655, FIG. 13(c) ); 4) 

object calls the DataManager object's SaveReport method to implementing Replace logic, e.g., replacement of "TAB" 

build a hash table to contain all of the report's data. The delimiters with appropriate "Comma" field delimiters (as 

CommunicationManager utilizes the RptManagerMsg 30 indicated at step 657 FIG. 13(c) ); 5) implementing Repeat/ 

object to create the ARD metadata message from the hash Padding logic, i.e., identifying compressed columns/values 

table, the WRSComm wrapper for direct communication and decompressing (or repeating) the values that were 

with the backend, and the WRSReportManagerUtilParser to compressed; 6) providing alphanumeric translations for any 

handle any errors thrown by the server. The Report Manager encoded data elements returned in the result set data file (as 

creates the Dispatcher object, and utilizes the services of the 35 indicated at step 659, FIG. 13(c)); and, 7) adding new 

RMParser class and validation objects. Upon determining computed/derived columns, e.g., percents, averages of col- 

that the client has sent a valid message, the appropriate umn data values, etc., as requested by customers on specific 

member function is invoked to service the request. The reports. 

response is built inside the esql wrapper function after Particularly, as shown in FIG. 12(b), the Formatter pro- 

obtaining the necessary information through the stored pro- 40 cess 395 reads the *.hdr files and *.data files from the 

cedure from the RM database. The Report Manager creates Decision Suite™ result set to obtain respective column 

the RMServerSocket object and sends the ARDA message names and report data. Particularly, the formatter process for 

back to the client. converting Column Headers from Information Advantage® 

As illustrated in FIG. 13(a), at step 630, in reference to column header names to column ids implements a lookup of 

user selection of a Save and Run report option, the report is 45 column ids in a column_id's table, shown in Appendix I, 

marked as scheduled and saved in a user_table in the Report based on column header names. 

Scheduler server 260 via the Report Manager. Subsequently, Then, the formatter process reads the request table 390 for 

as indicated at step 630, the Report Scheduler server 260 total/subtotal, threshold, etc. information associated with the 

generates an ARD message (Appendix D) and sends the current report request and determines any other formatting 

ARD message to StarODS DSS server for which the DSS 50 features to be enabled for a particular result set. As shown 

has a predefined interface, as described herein. in the example Request Table of Appendix I, parameters 

Next, as indicated at step 632, the DSS receives the passed to the formatter module indicate any report request 

request and acknowledges receipt. Specifically, when the specific details that are required by the Formatter. For 

request is received it is first validated with StarOE to ensure example, for report totals, a "total__mode" variable is used 

that the user is entitled to receive information about the 55 to indicate if report totals and/or sub-totals should be 

selected product corp and number(s). Once the request included. Particularly, Column IDs representing the data 

passes validation, the DSS IAIO reads the header to deter- columns upon which sub totaling is based are passed as 

mine which Data Mart will ultimately be queried. It then parameters to the Formatter process 395 and are referred to 

parses the metadata into a format which the COTS software as "Break Columns". At appropriate changes in values for 

can readily convert into a SQL statement, as indicated at step 60 these break columns, the formatter generates a subtotal line 

635, FIG. 13(6), and adds the report to the DSS report queue for subtotaling the applicable additive facts including, for 

based upon type (Daily, Weekly, Monthly, Adhoc) and example, Call Amount, Call Duration, and Call Count, 

associated DataMart, as indicated at step 638. It should be Furthermore, the formatter reads a Column id table 396 

understood that at this point, the request has been flagged as (detailed in Appendix I) to determine data types and if any 

submitted in the RM database, as indicated at step 633. 65 data translations are needed. 

From this point forward, DSS activity is controlled by a As computed/derived columns may be included or 

control process and progress or errors arc logged internally excluded from customer report requests, the Formatter pro- 
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cess 395 for calculating new computed/derived columns on 
specific customer-requested reports are provided on a report 
request basis. Example types of derived columns include: 1) 
Percents, e.g., based on the additive data facts pertinent to 
the report request and are typically based on report totals and 5 
row amounts for Call Amount, Call duration, and Call 
Count; 2) Row-wise derived data elements as requested, 
which represent data elements computed based on original 
additive data elements on a row by row basis (i.e., column 
x/column y for each row in the result data file) and typically 10 
include average calculations such as Average # of Minutes 
per Call, Average Amount per Call, and Average Amount per 
Minute. Appendix I illustrates a derived column "percent" 
calculation indicated in the Column ID table showing an 
equation for calculating a value of a particular value (C36) 15 
divided by a column total (CT36)xlOO. 

The Formatter process 395 may additionally perform 
alphanumeric translations for any encoded data elements 
returned in the result set data file by implementing appro- 
priate lookup in a Translation table 397, such as the example 20 
Translation Table provided in Appendix I, and replacing the 
code. 

Referring back to FIG. 13(c), after formatting the report, 
as indicated at step 660, a message is sent to the control 
process to update the request status table 391. It should be 25 
understood that, if a failure occurs during formatting, the 
error log is updated and a status message sent to the request 
status table 391, as well. Then, as indicated at step 665 (FIG. 
13(c) ), the formatter 395 creates a *.csv (Comma Separated 
Value) or .txt file, gives the file a unique name and saves the 30 
file. Preferably, a *.csv is the file generated if the report is 
successfully generated. 

As indicated at step 668, the * .csv report/data file is then 
"pushed", implementing FTP, to the StarODS server's direc- 
tory on the Inbox server 270. The StarODS server 400 is 35 
responsible for generating unique file names within their 
directory on the Inbox server 270, For example, the follow- 
ing directory and file naming conventions used for reports 
generated by the StarODS server are labeled inbox\files\ods 
with text files having the suffix *.txt or "\txt_zip 40 
(compressed), and comma separated files having a suffix 
*.csv or *.csv_zip (compressed). 

Finally, as indicated at step 670, once the file has been 
successfully transferred to the Priced reporting directory on 
the Inbox server, and the request status table 391 appropri- 45 
ately updated at step 675, the NRL process (FIG. ll(fc)) 
generates and transmits an NRL message to the RM Server 
250 notifying it of the report file name and location in the 
Inbox, requestor information, and if the transfer was suc- 
cessful. This is accomplished by using a "NRL 3 ' metadata 50 
message. 

Appendix B provides a table comprising the Notify 
Report Location parameters used for the NRL Metadata 
messaging sent by StarODS fulfilling server to the RM 
Server 250 when a requested report is complete. An example 55 
NRL message sent from the ODS server 400 to the RM 
server 250 is as follows: 

NRL<TYPE=Sim-Msg-40,ENTPID-00022924, 
USERID-dorod, STDRPTID«40,USERRPTID=3415 ) 
REQUESTID«20341,COMPRESS=0,L OC=/inbox/ 60 
files/testODS/STDRPTID43TM_082598_ 
084920.CSV, FSIZE«389,PRESORTED=0> 
An NRLA response is sent back to the DSS as shown in 
Appendix B. 

Once the RM server 250 has received the NRL message 65 
from the fulfilling server, it verifies the file's presence and 
builds a metadata file, e.g., by compressing the appropriate 
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metadata (for displaying the report) into a .MTD file. This 
.MTD file is utilized by the Report Viewer to know how to 
display the report. The Report Manager server creates a file 
including the metadata using the same file name as the 
report/data file, but having the following suffix: *.mtd or 
*.mtd_zip indicating a metadata or compressed metadata 
file, respectively. 

Appendix F details the parameters that are passed in the 
GET METADATA messaging for indicating to the Report 
Viewer how to display a requested report. For example, a 
GET METADATA message corresponding to an Priced TVS 
fulfilling server report is as follows: 

<METAD ATA = < CRITERIA- < Name = 

UsageSummary292 A ADescription« 
This report summarizes calls based on call type. A A 
Report_Level = <INBOUND<<90000001, 
90000001><NA,NAxNA, 
NA»INBOUND«90000002,90000002x,x, 
>>> A AOptions= A AScbeduling _Information= A AOne_ 
Time- A ADates-<06/01/l 99800:00/~07/01/l 99800:00, 
> A ATimezone -EST, Lang- 1 2 34, Cur r- 
2345>DEFAULT_GRAP H_M ODE- 

0 A ADEFAULT_GRAPH_TYPE-0 A ADEFINE_X„ 
AX1S-0 A AX_AXIS_COLUMN- "ADEFAUL 
T_Y_COLUMNS-o A A COLUMN_DlSPLAY_ 
ORDER- 

<105 A A114 A A67 A A62 A A36 A A6 1~A58*A63"A6 

4 A A66 A A65>"ASORT ALLOWED- 

rAPRESORTED-0~A 
PRESU B TO TALED = 1 A ATO TALM OD E= 0" AS 0 RT_ 

COLUMN S=<105A>~A 
SUBTOTAL_COLUMNS = o A ASELECTED_ 

SECTlON=0 A A 
METACOLUMN=<META^_COLUMN_JD=105 A A 
COLUMN_LABEL=Usage Description A ADATATYPE= 

S "AD ECIM AL=0 A A 
HIDEABLE-1 A AGRAPHABLE-0"AWIDTH- 

20~ACALCULATE-0~A 
CALCULATE„EXPRESSION=> A AMETACOLUMN= 

<META_COLUMN_ID=114 A A 
COLUMN_LABEL-R ange/ 

DistanceDescription A ADATATYPE-S'ADECIM 
AL=0~AHIDEABLE=1 A AGRAPHABLE=0 A AWIDTH= 

20 "ACALCU LATE =0 A A 
CALCULATE_EXPRESSION= > A AMETACOLUMN= 

<META_COLUMN_ID=67 A A 
COLUMN_LABEL = Calls A AD ATATYPE = 

rADECIMAL=0 A AHIDEABLE=l A A 
GRAPHABLE= 1 A AWIDTH = 7 A ACALCULATE = 

0 A ACALCULATE_EXPRESSION=> 
A AMETACOLUMN-<META_COLUMN_ID- 

62~ACOLUMN„LABEI^% Calls~A 
D ATATYPE=N A AD ECIM AL=1 A AHID E ABLE = 

1 A AGRAPHABLE=1 A AWIDTH=7 A A 
CALCULATE=0 A ACALCULATE_EXPRESSION=> A A 
METACOLUMN = <META_COLUMN_ID« 

36 A ACOLUMNJLABEL»Minutes A A 
DATATYPE = N A ADECIMAL= 1 A AHIDEABLE = 

1 A AGRAPHABLE=1 A AWIDTH=8 A A 
CALCULATE-0 A ACALCULATE_EXPRESSION-> A A 
M E TA COLUMN*<ME TA_ C O L U M N_ I D = 

61 A AC0LUMN_LABE1^% Min A A 
DATATYPE=N A ADECIMAL= 1 A AHIDEABLE = 
1 A AGR APHABLEa 1 A A 
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WIDTH = 5~ACALCULATE=0~ACALCULATE_ Inbox server 270 for adding an item into the StarWRS 

EXPRESSION^ *A system Inbox server 270, and the respective acknowledg- 

M E T A COLUMN-<ME T A_ COLUMN__ID- ment message format back from the Inbox server. In the "A" 

58~ACOLUMN_LABEL-Amounf ADATAT message found in Appendix C, the "LOC" field includes 

YPE CTADECIMAL=2 A AHIDEABLEol*A 5 m f ormat ion about where the report data is located. For 

GRAPHABLE-rAWIDTH-7-ACALCULATE- thTa^ricT^ 

0^ACALCULAre_EXPRESSION=> that a pnCCd ° DS tsmct ^ a aVadaWc 15 sh0Wn * S ' 

a \a pta pot ti \jTm mcta mi umm in A<CATEGORY-R,TYPE-traffic,REQUESTID-32197, 

^AmT?i Mn^5^ USERID-LynneLevy2, RPTID-150, PRIORITY-, 

63ACOLUMN„LABEL=%AmtA 10 C OMPRESS-0,UNOTIFY -0,MMADDR-, 

DATATYPE=N A ADECIMAL=1 A AHIDEABLE« MMTEXT-,PGT-,'P GPI N- ,PGTXT- , 

1 A AGRAPHABLE=1 A AWIDTH=5*A RPTCATEGORY -Service Location & Hour, 

CALCULAre-0^ACALOTI^IE_EXPRESSION->-A LOC=/inbox/files/ods/902512294STDRPTID10.CSV, 

METACOLUMNn<META_COLUMN_IDo ENTP 

64*ACOLUMN_LABEL=Avg Min/Call 15 I D-10324488,RQSTDT-1 998-01-02 

~ADATATYPE-N A ADECIMAL-2~AHIDEABLE- 15:18, FSIZE=3705,RPTTITLE=Summary by Service 

TAGRAPHABLE-rA Location and Hour,MSIZE=3322> 

WIDTH = 12 A ACALCULATE=0"ACALCULATE Particularly, the RM server supplies a metadata "A" 

EXPRESSION^ A A 20 message to the Inbox indicating the FTP file location. Via the 

METACOLUMN = <META_COLUMN_ID = report viewer, the report is now available for viewing, 

66 A ACOLUMN_XABEL=Avg downloading, saving, or printing by the user, and as 

Amt/CairA described in further detail in co-pending U.S. patent appli- 

DATATYPE=N A ADECIMAL=2"AHIDEABLE= ^ ^^^FOR^^iff™^ 

1"AGRAPHABLE=1"AWIDTH=12 25 ™ EB B , AS , ED ^, B ° X MANAGEMENT, 

the contents and disclosure or which are mcorpo rated by 

*ACALCULATE-0 A ACALCULATE_EXPRESSION- reference as if fully set forth herein. Particularly, as shown 

> A in the exemplary nMCI home page in FIG. 4, the nMCI 

METACOLUMN = <META_COLUMN__ID = Interact Message Center icon 77 may be selected which will 

65 A ACOLUMN__LABEL=Avg Amt/MnTA 30 cause the display of a web page including the message center 

D ATATYPE-N'ADECIM AL-2"AHIDEABLE- dialog window. From the message center dialog window, a 

l A AGRAPHABLE-rA user may select from among three tabs, one of which, a 

WIDTH=11 A ACALCULATE=0"ACALCULATE_ re P orts tob > enables ihe retrieval of both a data file and a 

EXPRESSION=>» metadata file from the Inbox Server corresponding to those 

* nfrTA^AT* ^niTTUTA vt i f T* .35 reports that have been run and available for customer 

*<METADATA= <CRITERIA« <Name=My Report, . . Tf .. j j r j* i u >u 

Total Totals viewing. Information provided for display by the message 

center display 325 is provided by the User__table which 

are located at the bottom of the report., keeps track of me status of ^ reports for a particular ^ 

Description=My report description, By double-clicking a chosen report, a report viewer appli- 

Number_Dialed=<800#l, 800#2, 800#n>, 40 cation is enabled to display the chosen report on a web-page. 

Scheduling_Information= Recurring, Dates- Monthly» To vicw me re P ort me user mc re P ort ^ me re P ort 

DEFAULT GRAPH MODE-1, DEFAULT *°t a PP ro P riatc ™ w arc goaded to the user 

GRAPH_fVPE-l, " " (^Oworkstauon. 1 1 CTr - 

' As mentioned herein with respect to FIG. 3, the messages 

DEFINE_X_AXIS«1, X_AXIS_COLUMN=2, 45 created 5y mc clicnt Java so f tware are transmitted to the 

DEFAULT_Y_COLUMNS=<5,6>, StarWeb (DMZ) Server 44 over HTTPS. For incoming 

C0LUMN_DISPLAY_0RDER=<1,2,3,4,5,6>, (client-to-server) communications, the DMZ Web servers 44 

C0LUMN_ST0RED_0RDER-<4,3,2,5,6,1>, SORT_ decrypt a request, authenticate and verify the session infor- 

ALLOWED=l matioD. The logical message format from the client to the 

PRESORTED - 1, TOTALMODE-3, SUBTOTCOL-<5, 50 Web server is shown as follows: 

6> SELECTED II TCP/IP || encryption || http || web header || dispatcher 

SECTION-l, METACOLUMNo<META_COLUMN_ ^der || proxy-specific data || 

jjj^j . where "|| separates a logical protocol level, and protocols 

^~x°,,\,v T T . ..^ , _ _ m „ „ nested from left to right. FIG. 14 illustrates a specific 

CO n ^ N - LABEL-namc, DATATYPE -S, 55 message sent from the client browser to the desired middle 

DECIMAL=0, HIDEABLE=1, Uer server for the particu i ar application. As shown in FIG. 

GRAPHABLE=0, WIDTH-10, CALCULATE- 1, 14, the client message 340 includes an SSL encryption 

CALCULATE_EXPRESSION=<4 / 7»» header 342 and a network-level protocol HTTP/POST 

Once the metadata file corresponding to the requested header 344 which are decrypted by the DMZ StarWeb 

report is build by the Report Manager, the RM ftp's the 60 Server(s) 44 to access the underlying message; a DMZ Web 

.MTD file to the Inbox server. The RM server additionally header 346 which is used to generate a cookie 341 and 

updates a User_report table status field with a status "C" transaction type identifier 343 for managing the client/server 

indicating completion. session; a dispatcher header 345 which includes the target 

Once the Report Manager has updated the status field, the proxy identifier 350 associated with the particular type of 

RM server 250 then adds the report to the user's Inbox. 65 transaction requested; proxy specific data 355 including the 

Appendix C provides a table showing the fields for the application specific metadata utilized by the target proxy to 

metadata messaging between the RM server 250 and the form the particular messages for the particular middle tier 
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server providing a service; and, the network-level HTTP/ header. There should be no attempt to connect to processes 

POST trailer 361 and encryption trailer 366 which are also outside the proxy, e.g. the back-end application services, 

decrypted by the DMZ Web server layer 44. The next portion indicates the Session key 125 which is the 

After establishing that the request has come from a valid unique session key or "cookie" provided by the Web 

user and mapping the request to its associated session, the 5 browser and used to uniquely identify the session at the 

request is then forwarded through the firewall 556 over a browser. As described above, since the communications 

socket connection 33 to one or more decode/dispatch servers middleware is capable of supporting four types of transport 

46 located within the corporate Intranet 60. The messaging mechanisms, the next portion of the common protocol 

sent to the Dispatcher will include the user identifier and header indicates the message type/mechanism 130 which 

session information, the target proxy identifier, and the 10 may be one of four values indicating one of the following 

proxy specific data. The decode/dispatch server 46 authen- four message mechanisms and types: 1 Synchronous 

ticates the user's access to the desired middle-tier service. transaction, e.g., a binary 0; 2) Asynchronous request, e.g., 

As shown in FIG. 14, the StarWeb server forwards the a binary 1; 3) Asynchronous poll/reply, e.g., a binary 2; 4) 

Dispatcher header and proxy-specific data to the Dispatcher, bulk transfer, e.g., a binary 3, 

"enriched" with the identity of the user (and any other 15 Additionally, the common protocol header section 

session-related information) as provided by the session includes an indication of dispatcher-assigned serial number 

data/cookie mapping, the target proxy identifier and the 135 that is unique across all dispatcher processes and needs 

proxy-specific data. The dispatch server 46 receives the to be coordinated across processes (like the Web cookie (see 

requests forwarded by the Web server(s) 44 and dispatches above)), and, further, is used to allow for failover and 

them to the appropriate application server proxies. 20 process migration and enable multiplexing control between 

Particularly, as explained generally above with respect to the proxies and dispatcher, if desired. A field 140 indicates 

FIG. 7, the dispatch server 46 receives request messages the status is unused in the request header but is used in the 

forwarded by the DMZ Web servers and dispatches them to response header to indicate the success or failure of the 

the appropriate server proxies. The message wrappers are requested transaction. More complete error data will be 

examined, revealing the user and the target middle-tier 25 included in the specific error message returned. The status 

service for the request. A first-level validation is performed, field 140 is included to maintain consistency between 

making sure that the user is entitled to communicate with the requests and replies. As shown in FIG. 16(a), the proxy 

desired service. The user's entitlements in this regard are specific messages 375 are the metadata message requests 

fetched by the dispatch server from Order Entry server 280 from the report requestor client and can be transmitted via 

at logon time and cached. Assuming that the Requestor is 30 synchronous, asynchronous or bulk transfer mechanisms, 

authorized to communicate with the target service, the Likewise, the proxy specific responses are metadata 

message is then forwarded to the desired service's proxy, response messages 380 again, capable of being transmitted 

which, in the accordance with the principles described via a synch, asynch or bulk transfer transport mechanism, 

herein, comprises: 1) a report manager proxy 250' corre- It should be understood that the application server proxies 

sponding to the RM Server 250, 2) a report scheduler proxy 35 can either reside on the dispatch server 46 itself, or, 

260' corresponding to the RS Server 260, and 3) an inbox preferably, can be resident on the middle -tier application 

server proxy 270' corresponding to the Inbox Server 270. server, i.e., the dispatcher front end code can locate proxies 

Each of these proxy processes further performs: a validation resident on other servers. 

process for examining incoming requests and confirming As mentioned, the proxy validation process includes 

that they include validly formatted messages for the service 40 parsing incoming requests, analyzing them, and confirming 

with acceptable parameters; a translation process for trans- that they include validly formatted messages for the service 

lating a message into an underlying message or networking with acceptable parameters. If necessary, the message is 

protocol; and, a management process for managing the translated into an underlying message or networking proto- 

communication of the specific customer request with the col. A list of Report Manager and Inbox proxy error mes- 

middle-tier server to actually get the request serviced. Data 45 sages can be found in Appendix E. If no errors are found, the 

returned from the middle -tier server is translated back to proxy then manages the communication with the middle -tier 

client format, if necessary, and returned to the dispatch server to actually get the request serviced. The application 

server as a response to the request. proxy supports application specific translation and commu- 

FIGS. 15(a) and 15(6) are schematic illustrations showing nication with the back-end application server for both the 

the message format passed between the Dispatcher 46 and 50 Web Server (java applet originated) messages and applica- 

the application specific proxy (FIG. 15(a)) and the message tion server messages. 

format passed between the application specific proxy back to Particularly, in performing the verification, translation 

the Dispatcher 46 (FIG. 15(fe)). As shown in FIG. 15(a), all and communication functions, the Report Manager server, 

messages between the Dispatcher and the Proxies, in both the Report Scheduler server and Inbox server proxies each 

directions, begin with a common header 110 to allow 55 employ front end proxy C++ objects and components. For 

leverage of common code for processing the messages. A instance, a utils.c program and a C++ components library, is 

first portion of the header includes the protocol version 115 provided for implementing general functions/objects. Vari- 

which may comprise a byte of data for identifying version ous C++ parser objects are invoked which are part of an 

control for the protocol, i.e., the message format itself, and object class used as a repository for the RM metadata and 

is intended to prevent undesired mismatches in versions of 60 parses the string it receives. The class has a build member 

the dispatcher and proxies. The next portion includes the function which reads the string which contains the data to 

message length 120 which, preferably, is a 32-bit integer store. After a message is received, the parser object is 

providing the total length of the message including all created in the RMDispatcher.c object which is file contain- 

headers. Next is the echo/ping flag portion 122 that is ing the business logic for handling metadata messages at the 

intended to support a connectivity test for the dispatcher- 65 back-end. It uses the services of an RMParser class. Upon 

proxy connection. For example, when this flag is non-zero, determining that the client has sent a valid message, the 

the proxy immediately replies with an echo of the supplied appropriate member function is invoked to service the 
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request. Invocation occurs in MCIRMServerSocket.C when 
an incoming message is received and is determined not to be 
a talarian message. RMSErverSocket.c is a class implement- 
ing the message management feature in the Report Manager 
server. Public inheritance is from MCIServerSocket in order 
to create a specific instance of this object. This object is 
created in the main loop and is called when a message needs 
to be sent and received; a Socket.c class implementing client 
type sockets under Unix using, e.g., TCP/IP or TCP/UDP. 
Socket.C is inherited by ClientSocket.C:: Socket 
(theSocketType, thePortNum) and ServerSocket.C: Socket 
(theSocketlVpe, thePortNum) when ClientSocket or Serv- 
erSocket is created. A ServerSocket.C class implements 
client type sockets under Unix using either TCP/IP or 
TCP/UDP. ServerSocket.C is inherited by RMServerSocket 
when RMServerSocket is created. An InboxParser.c class 
used as a repository for the RM Metadata. The class' "build" 
member function reads the string which contains the data to 
store and the class parses the string it receives. After a 
message has been received, the MCHnboxParser object is 
created in inboxutl.c which is a file containing the functions 
which process the Inbox requests, i.e, Delete, List, Fetch and 
Update (Appendix G). Additional objects/classes include; 
Environ.c which provides access to a UNIX environment; 
Pro cess, c which provides a mechanism to spawn slave 
processes in the UNIX environment; Daemon. c for enabling 
a process to become a daemon; Exception.c for exception 
handling in C++ programs; and, RMlog.c for facilitating RM 
logging. In addition custom ESQL code for RM/database 
interface is provided which includes the ESQC C interface 
(Informix) stored procedures for performing the ARD, DRD, 
DUR, URS, GRD, CRD, and GPL messages. The functions 
call the stored procedures according to the message, and the 
response is build inside the functions depending on the 
returned values of the stored procedures. A mainsql.c pro- 
gram provides the ESQL C interface for messages from the 
report manager and report viewer. 

A list of Report Manager and Inbox proxy error messages 
can be found in Appendix E. 

Outgoing (server-to-client) communications follow the 
reverse route, i.e., the proxies will feed responses to the 
decode/dispatch server, which will encrypt the client-bound 
messages and communicate them to the DMZ Web servers 
over the socket connection. The Web servers will forward 
the information to the client using SSL. The logical message 
format returned to the client from the middle tier service is 
shown as follows: 

|| TCP/IP || encryption || http || web response || dispatcher 
response || proxy-specific response || 
where || separates a logical protocol level, and protocols 
nested from left to right. 

The foregoing merely illustrates the principles of the 
present invention. Those skilled in the art will be able to 
devise various modifications, which although not explicitly 
described or shown herein, embody the principles of the 
invention and are thus within its spirit and scope. 

What is claimed is: 

1. A Web/Internet based reporting system for communi- 
cating data information from an enterprise intranet database 
to a client workstation via an integrated interface, said 
system comprising: 

client browser application located at said client worksta- 
tion for enabling interactive Web based communica- 
tions with said reporting system, said client workstation 
identified with a customer and providing said integrated 
interface; 

at least one secure server for managing client sessions 
over the Internet, said secure server supporting a first 
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secure socket connection over a first firewall enabling 
encrypted communication between said client browser 
application and said secure server; 
report manager server for maintaining an inventory of 

5 reporting items associated with a customer and man- 
aging the reporting of customer-specific data informa- 
tion in accordance with a customer report request 
message, said report manager generating a response 
message including a metadata description of said 

10 reporting items included in a report request; 

dispatch server for communicating with said secure server 
through a second firewall over a second socket 
connection, said first secure and second socket connec- 
tions forming a secure communications link, said dis- 

15 patch server enabling forwarding of a report request 
message to said report manager server; and 
operational data storage device for receiving a metadata 
description of a requested report from said report 

2{} manager server and retrieving said customer-specific 
data from said enterprise intranet database in accor- 
dance with said received metadata description; 
wherein said retrieved data and said metadata description 
of said reporting items are utilized to generate a com- 

25 pie ted report for presentation to said customer via said 
interface. 

2. The reporting system as claimed in claim 1, further 
including client report requester application for enabling 
presentation of a report request menu including various 

30 reporting options for said customer in accordance with 
predetermined customer entitlements, said reporting options 
including creation and customization of said reporting items. 

3. A Web/Internet based reporting system for communi- 
cating data information from an enterprise intranet database 

35 to a client workstation via an integrated interface, said 
system comprising: 
client browser application located at said client worksta- 
tion for enabling interactive Web based communica- 
tions with said reporting system, said client workstation 
40 identified with a customer and providing said integrated 
interface; 

at least one secure server for managing client sessions 
over the Internet, said secure server supporting a first 
secure socket connection over a first firewall enabling 

45 encrypted communication between said client browser 
application and said secure server; 
report manager server for maintaining an inventory of 
reporting items associated with a customer and man- 
aging the reporting of customer-specific data informa- 

50 tion in accordance with a customer report request 
message, said report manager generating a response 
message including a metadata description of said 
reporting items included in a report request; 

55 dispatch server for communicating with said secure server 
through a second firewall over a second socket 
connection, said first secure and second socket connec- 
tions forming a secure communications link, said dis- 
patch server enabling forwarding of a report request 

60 message to said report manager server; and 

operational data storage device for receiving a metadata 
description of a requested report from said report 
manager server and retrieving said customer-specific 
data from said enterprise intranet database in accor- 

65 dance with said received metadata description; 

client report requestor application for enabling presenta- 
tion of a report request menu including various report- 
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ing options for said customer in accordance with pre- 
determined customer entitlements, said reporting 
options including creation and customization of said 
reporting items; and 
report scheduler server for enabling said operational data 
storage device to retrieve said customer-specific data at 
predetermined times in accordance with a reporting 
schedule, 

wherein said retrieved data and said metadata description 
of said reporting items are utilized to generate a com- 

. pleted report for presentation to said customer via said 
interface. 

4. The reporting system as claimed in claim 3, wherein 
said client report requestor application further generates said 
report request message in response to user selection of a 
specific report option for communication over said secure 
communications link, for receipt by said report manager 
server. 

5. The reporting system as claimed in claim 3, wherein 
said second operational data storage device for accessing 
customer-specific data includes a mechanism for formatting 
said customer-specific data information in accordance with 
said metadata description, said customer-specific data being 
formatted for display at said client workstation via said 
integrated interface. 

6. The reporting system as claimed in claim 3, wherein 
said scheduler server enables said operational data storage 
device to retrieve said customer-specific data at a customer- 
specified frequency. 

7. The reporting system as claimed in claim 6, wherein 
said report manager server includes a process for generating 
requestor applets for communication over said secure com- 
munications link to said client workstation, one of said 
applets capable of presenting said reporting items to a 
requesting customer via said interface. 

8. The reporting system as claimed in claim 3, wherein 
said customer specific data information relates to priced call 
detail data representing usage of a customer's telecommu- 
nications network. 

9. The reporting system as claimed in claim 3, wherein 
said enterprise intranet database is organized as one or more 
datamart storage devices, said operational data storage 
device determining one or more specific datamart storage 
devices from which o access said customer-specific data 
information in accordance with a report metadata descrip- 
tion. 

10. The reporting system as claimed in claim 9, further 
including a data harvester device for periodically inputting 
up-to-date data information into said one or more datamart 
storage devices. 

11. The reporting system as claimed in claim 10, wherein 
said one or more datamart storage devices is organized 
according to a star-schema topology to facilitate retrieval of 
customer-specific data therefrom, 

12. The reporting system as claimed in claim 3, further 
including subscribe and publish communications interface 
between said report manager server and said operational 
data storage device, said metadata descriptions being trans- 
lated by said report manager server to generate published 
messages for receipt by said operational data storage device. 

13. The reporting system as claimed in claim 3, further 
including a client report viewer application for receiving 
said customer specific data of a requested report and a 
metadata description of a report type and generating said 
report for display at said interface. 

14. A method for reporting data information from an 
enterprise intranet database to a client terminal via an 
integrated interface, said method comprising: 
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enabling interactive Web based communications between 
said client terminal identified with a customer and a 
first secure server over a first secure socket connection 
over a first firewall, said socket connection enabling 
encrypted communication between said browser appli- 
cation client and said secure server; 

enabling communications between said secure server and 
a second server through a second firewall over a second 
socket connection, said first and second sockets form- 
ing a secure communications link, said second server 
enabling forwarding of a report request message and an 
associated report response message back to said client 
browser over said secure conmmunications link; 

accessing reporting items based on a customer identity 
and report name from a first database, and generating a 
response message including a metadata description of 
said reporting items; 

retrieving said customer-specific data from said enterprise 
intranet database in accordance with said metadata 
description; and 

generating a completed report for said customer from said 
metadata description of said reporting items and said 
accessed customer-specific data via said interface. 

15. The method as claimed in claim 14, further including 
the step of presenting a report request menu including 
various reporting options for said customer in accordance 
with predetermined customer entitlements, said reporting 
options including creation and customization of said report- 
ing items. 

16. The method as claimed in claim 15, further including 
the step of enabling retrieval of said customer-specific data 
at a predetermined time in accordance with a reporting item. 

17. A method for reporting data information from an 
enterprise intranet database to a client terminal via an 
integrated interface, said method comprising: 

enabling interactive Web based communications between 
said client terminal identified with a customer and a 
first secure server over a first secure socket connection, 
said socket connection enabling encrypted communi- 
cation between said browser application client and said 
secure server; 

enabling communications between said secure server and 
a second server over a second socket connection, said 
first and second sockets forming a secure communica- 
tions link, said second server enabling forwarding of a 
report request message and an associated report 
response message back to said client browser over said 
secure communications link; accessing reporting items 
based on a customer identity and report name from a 
first database, and generating a response message 
including a metadata description of said reporting 
items; retrieving said customer-specific data from said 
enterprise intranet database in accordance with said 
metadata description; 

generating a completed report for said customer from said 
metadata description of said reporting items and said 
accessed customer-specific data via said interface; 

presenting a report request menu including various report- 
ing options for said customer in accordance with pre- 
determined customer entitlements, said reporting 
options including creation and customization of said 
reporting items; and 

periodically enabling retrieval of said customer-specific 
data. 

18. The method as claimed in claim 17, further including 
the step of generating said report request message in 
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response to user selection of a specific report option for 
communication over said secure communications link, and 
communicating a response message over said communica- 
tions link for display at said client terminal 

19. The method as claimed in claim 17, wherein said step 
of accessing customer-specific data includes the step of 
formatting said customer-specific data information in accor- 
dance with said metadata description, and storing said 
customer-specific data information in a database. 

20. The method as claimed in claim 16, further including 
generating requester applets for communication over said 
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secure communications link to said client terminal, said 
applet presenting said reporting items to a requesting cus- 
tomer via said interface. 

21. The method as claimed in claim 17, wherein said 
enterprise intranet database is organized as one or more 
datamarts, said method including determining one or more 
specific datamarts from which to access said customer- 
specific data information. 
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